RE: Microsoft Canards

to determining -> to determine

inconsistant -> inconsistent

--1373580-20395-967641124=:-1025299-- Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23950 for ietf-imapext-bks; Wed, 30 Aug 2000 06:05:03 -0700 (PDT) Received: from ns1.syntegra.com (ns1.syntegra.com [150.143.16.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23945 for ; Wed, 30 Aug 2000 06:05:02 -0700 (PDT) Received: from [129.179.161.11] by ns1.cdc.com with ESMTP for ietf-imapext@imc.org; Wed, 30 Aug 2000 08:05:32 -0500 Received: from csol1.udev.cdc.com by cdsms.cdc.com with ESMTP for ietf-imapext@imc.org; Wed, 30 Aug 2000 08:05:31 -0500 Received: from isdn-220-114.arh-dialin.cdc.com by csol1.udev.cdc.com with ESMTP; Wed, 30 Aug 2000 08:05:29 -0500 Date: Wed, 30 Aug 2000 09:06:12 -0400 From: "warren.l.brown@syntegra.com" Subject: typos in draft-ietf-imapext-sort-05.txt To: "MRC@CAC.Washington.EDU" cc: "ietf-imapext@imc.org" Message-Id: Content-Language: en-USA 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: tenatively -> tentatively determing -> determine inconsistant -> inconsistent Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16013 for ietf-imapext-bks; Wed, 30 Aug 2000 03:49:15 -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 DAA16006 for ; Wed, 30 Aug 2000 03:49:14 -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 GAA23534; Wed, 30 Aug 2000 06:50:14 -0400 (EDT) Message-Id: <200008301050.GAA23534@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-02.txt Date: Wed, 30 Aug 2000 06:50:14 -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-02.txt Pages : 12 Date : 29-Aug-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-02.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-02.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-02.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: <20000829112114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-thread-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-thread-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000829112114.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id DAA15999 for ietf-imapext-bks; Wed, 30 Aug 2000 03:49:11 -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 DAA15993 for ; Wed, 30 Aug 2000 03:49:09 -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 GAA23520; Wed, 30 Aug 2000 06:50:09 -0400 (EDT) Message-Id: <200008301050.GAA23520@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-sort-05.txt Date: Wed, 30 Aug 2000 06:50:09 -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 - SORT EXTENSION Author(s) : M. Crispin, K. Murchison Filename : draft-ietf-imapext-sort-05.txt Pages : 10 Date : 29-Aug-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-ietf-imapext-sort-05.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-sort-05.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-sort-05.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: <20000829112105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-imapext-sort-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-imapext-sort-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000829112105.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA02889 for ietf-imapext-bks; Wed, 30 Aug 2000 01:12:18 -0700 (PDT) Received: from sendflowersamerica.com ([206.168.43.194]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA01618; Wed, 30 Aug 2000 01:00:01 -0700 (PDT) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Wed, 30 Aug 2000 01:32:17 Message-Id: <620.108063.29555@sendflowersamerica.com> Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA27280 for ietf-imapext-bks; Fri, 25 Aug 2000 12:06:20 -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 MAA27276 for ; Fri, 25 Aug 2000 12:06:19 -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 MAA02540 for ; Fri, 25 Aug 2000 12:06:55 -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 MAA29223 for ; Fri, 25 Aug 2000 12:06:50 -0700 (PDT) Date: Fri, 25 Aug 2000 12:05:10 -0700 From: Chris Newman To: IMAP Extensions WG Subject: Summary: SORT/THREAD/VIEW debate Message-ID: <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: These are my opinions on where we stand on the SORT/THREAD/VIEW debate. Please reply to this message if you think I've missed a substantial bullet item or substantially misworded a bullet item. Please use another thread for issue debate. Note that I hold strong opinions on some (but not all) of the points of contention. Thus it is quite likely that my perception of the opposite position is biased or not accurate, so please help me fix such mistakes. In some places I have added points (to both sides) which weren't expressed, but I think should have been. I suspect there is WG rough concensus on the following: * It must be possible for a server to advertise and support the deployed SORT and THREAD extensions in addition to whatever we standardize. * The deployed SORT and THREAD extensions offer a significant improvement over the base spec for online clients. * The current VIEW draft does not work well with a caching online client if there is a desire to preserve the cache across VIEW changes. * It is desirable for a caching online client to preserve the cache across VIEW changes. * Semi dynamic updates of a client view are desirable. * Fully dynamic updates of a client view are desirable. * We need to be able to extend SORT with additional keys. * THREAD should be extensible since there are at least two useful algorithms. * Windowing introduces significant complexity. * Having two ways to get SORT/THREAD positions is undesirable. 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. Pro position: * Pine needs this * one-shot SORT/THREAD are already deployed * Persistant result facility untested and will delay SORT/THREAD Con position: * Protocol is simpler without one-shot facility * Removes potential to have two ways to do same/similar functions * No scenario provided that demonstrates one-shot is useful when persistant is available. (2) Desire for scalability on the basis of mailbox size (Windowing). Pro position: * Need to design for clients with limited/expensive bandwidth * Need to design for clients with limited RAM * Need to plan for the future * Desire to use mailboxes for mailing list archives * Desire to use mailboxes for storage and virtual views for navigation Con position: * Users can't handle large mailboxes * Most software today can't handle large mailboxes * The complexity that windowing adds is not worth the benefit (3) Desire to collapse related functionality into a minimal number of capability items. Pro Position: * Simplifies client UI * Simplifies code paths and protocol testing * Encourages deployment of related functionality as a unit so servers support a broader range of clients initially, rather than deploying a partial solution (with workarounds in some clients) and waiting for market to force support for more complete solution. * Avoids two ways of doing same/similar things * Reluctance to standardize what is believed to be a partial solution. Con Position: * SORT/THREAD already deployed separately * Want to separate functions which might not win in marketplace from those which will so the end result is simpler. * Modularity of design should be expressed in capability list - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19369 for ietf-imapext-bks; Fri, 25 Aug 2000 08:57:59 -0700 (PDT) Received: from smtp4.andrew.cmu.edu (SMTP4.ANDREW.CMU.EDU [128.2.10.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19364 for ; Fri, 25 Aug 2000 08:57:57 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp4.andrew.cmu.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7PFwTg17494; Fri, 25 Aug 2000 11:58:29 -0400 Date: Fri, 25 Aug 2000 11:58:29 -0400 Message-Id: <200008251558.e7PFwTg17494@smtp4.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Lawrence Greenfield Cc: Chris Newman , IMAP Extensions WG In-reply-to: Subject: Re: SORT, THREAD, and VIEW References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 25 Aug 2000 00:58:21 -0700 (PDT) From: Mark Crispin On Thu, 24 Aug 2000 22:40:06 -0400, Lawrence Greenfield wrote: > I'm sorry, this example is somewhat bogus. > Are you trying to simulate a client with a cache or without a cache? Let me explain. Sorry, still confused! It is unlikely that a client will ever do "VIEW FETCH 1:20 ENVELOPE" because then the client would be obliged to re-fetch the same data every time the VIEW is redefined. Instead of caching by VIEW indexes, since these are even more ephemeral than message sequence numbers, the client will cache either by message sequence number or by UID. So, the client has some some (or all) message data cached, indexed either by message sequence number or by UID. After doing the VIEW SET SORT command, it now wants to know which view indexes translate to which message sequence numbers or UIDs, so it can do cache lookup to get the data, and only do a FETCH via IMAP if the data isn't in the cache. I chose my example carefully. Notice that I broke out the cases: no cache, a partial cache, and a full cache. So I guess at this point I'm somewhat confused (as usual!). What is the point of the VIEW/SORT/THREAD extensions? Below I outline some things that we might be trying to improve and some naive guesses about the impact of the various extensions on them. I guess if someone can clue me in with what we're trying to accomplish, I'd understand this latest discussion much better. What's the important items: 1) minimize bandwidth consumed 2) maximize responsiveness to the user 3) minimize CPU time for the client 4) minimize memory footprint for a client 5) increase server scalability Of the proposals so far, (1) may be best achieved by SORT with built-in narrowing, as suggested by Chris, for clients with a (partial) cache. But I'm not sure. Under most networks that exist today, (2) is best done by a pipelined VIEW/FETCH like I showed, since latency dominates in small fetches like a FETCH 1:20. (This is also true for a client with a partial cache if there's a single message in 1:20 that it doesn't have cached.) I do not believe that (3) is worth optimizing for. (Yes, CPU consumes battery. However, most of the people I know who worry about CPU/battery tradeoffs are doing video decoding via wireless etc, not e-mail reading.) (4) is best achieved by VIEW by a client with NO cache. I guess VIEW/SORT/THREAD can help with (5) in cases where clients would download absurd amounts of data (100,000 messages or whatever) when they really only want 20 and then they'll go away. Larry Received: by ns.secondary.com (8.9.3/8.9.3) id BAA15639 for ietf-imapext-bks; Fri, 25 Aug 2000 01:10:13 -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 BAA15634 for ; Fri, 25 Aug 2000 01:10:11 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id BAA16379; Fri, 25 Aug 2000 01:10:44 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (rfort@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 BAA04844; Fri, 25 Aug 2000 01:10:44 -0700 Date: Fri, 25 Aug 2000 00:58:21 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Lawrence Greenfield cc: IMAP Extensions WG , Chris Newman In-Reply-To: <200008250240.e7P2e6g17020@smtp4.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, 24 Aug 2000 22:40:06 -0400, Lawrence Greenfield wrote: > I'm sorry, this example is somewhat bogus. > Are you trying to simulate a client with a cache or without a cache? Let me explain. It is unlikely that a client will ever do "VIEW FETCH 1:20 ENVELOPE" because then the client would be obliged to re-fetch the same data every time the VIEW is redefined. Instead of caching by VIEW indexes, since these are even more ephemeral than message sequence numbers, the client will cache either by message sequence number or by UID. So, the client has some some (or all) message data cached, indexed either by message sequence number or by UID. After doing the VIEW SET SORT command, it now wants to know which view indexes translate to which message sequence numbers or UIDs, so it can do cache lookup to get the data, and only do a FETCH via IMAP if the data isn't in the cache. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA14817 for ietf-imapext-bks; Fri, 25 Aug 2000 00:54:50 -0700 (PDT) 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 AAA14812 for ; Fri, 25 Aug 2000 00:54:49 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id AAA32699; Fri, 25 Aug 2000 00:55:23 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (neil@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 AAA04560; Fri, 25 Aug 2000 00:55:23 -0700 Date: Fri, 25 Aug 2000 00:35:01 -0700 (PDT) From: Mark Crispin Subject: re: Modularity vs. Protocol options To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <984785.3176137441@localhost> 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 Thu, 24 Aug 2000 20:24:01 -0700, Chris Newman wrote: > For example, SORT and THREAD are both functions to order the mailbox. If > one can occur without the other, then the client's ordering user interface > has to deal with 4 cases (neither, both, SORT only, THREAD only). The > entire ordering interface has to be disabled or simulated in the first > case. In the latter three, the ordering interface is enabled but in the > latter two there are sub-cases which must be disabled or simulated. My > conclusion is that, if possible, we should advertise both SORT and THREAD > with the same capability (ORDER?) as that reduces client complexity. This presupposes that all forms of "ordering" can be coalesced into a single immutable extension. But THREAD, by definition, is extensible; new algorithms can be added (and will be added). Threading is also fundamentally different from sorting; sorts are flat whereas threads have structure. I do not believe that, even with SORT2, there will ever be a closed-end, comprehensive set of "orderings" in IMAP that preclude any client-based implementation of ordering. Clients will always have their own ideas of how to "order"; furthermore, clients will probably always lead IMAP in having new "orderings" first. Therefore, different levels of server-based ordering technology will always exist. No purpose is served by the incompatibility of a change to "ORDER". A better argument would be for SORT2 to take an equals sign, ala THREAD, so that new SORT criteria could be added without having to create SORT3. That is, instead of "SORT2", have "SORT=ANSWERED SORT=BCC SORT=DELETED ..." The current set of SORT criteria would remain mandatory, preserving compatibility. This also sets a precedent for extending SEARCH, e.g. SEARCH=REGEX. There's significant potential here. > Is there any deployed server software which implements SORT and not > _THREAD_ (or vice versa) and considers that a useful case to preserve in > future versions? Some servers only have THREAD=ORDEREDSUBJECT; others have both this and THREAD=REFERENCES. Although the trend is for universal implementation of THREAD=REFERENCES, we can not assume that it will end there. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA29866 for ietf-imapext-bks; Thu, 24 Aug 2000 21:08:20 -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 VAA29862 for ; Thu, 24 Aug 2000 21:08:18 -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 VAA02573; Thu, 24 Aug 2000 21:08:52 -0700 (PDT) Received: from [192.129.100.100] (dsl198-113.Eng.Sun.COM [129.146.198.113]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA22914; Thu, 24 Aug 2000 21:08:51 -0700 (PDT) Date: Thu, 24 Aug 2000 21:07:15 -0700 From: Chris Newman To: Mark Crispin cc: IMAP Extensions WG Subject: re: Simplified VIEW strawman Message-ID: <1140799.3176140035@[192.129.100.100]> In-Reply-To: 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: --On Thursday, August 24, 2000 19:09 -0700 Mark Crispin wrote: > On Thu, 24 Aug 2000 18:12:39 -0700, Chris Newman wrote: >> While I'm less concerned than Mark about the difference in "blather" >> since a good compression layer would largely fix that among many other >> "blather" problems in IMAP/822/MIME/content > > The same argument ("it's just a compression problem") can be used against > your claims of "non-scalability" of the existing top-level SORT and > THREAD. Not true. Compression algorithms eliminate repetative information, thus: * blather blather 5 blather * blather blather 4 blather * blather blather 8 blather * blather blather 10 blather * blather blather 30 blather * blather blather 3 blather * blather blather 7 blather is equivalent to: * gunk 5 4 8 10 30 3 7 when compression is used (presuming the blather is the same on all lines). But most compression algorithms won't help significantly with a list of ASCII numbers (beyond the wasted bits in ASCII), and none will change a O(n) quantity of data into a O(1) quantity of data. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id UAA27047 for ietf-imapext-bks; Thu, 24 Aug 2000 20:28:41 -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 UAA27043 for ; Thu, 24 Aug 2000 20:28:40 -0700 (PDT) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id UAA09411; Thu, 24 Aug 2000 20:29:13 -0700 Received: from Tomobiki-Cho.CAC.Washington.EDU (rambo@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 UAA29450; Thu, 24 Aug 2000 20:29:13 -0700 Date: Thu, 24 Aug 2000 19:09:05 -0700 (PDT) From: Mark Crispin Subject: re: Simplified VIEW strawman To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <629316.3176129559@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 Thu, 24 Aug 2000 18:12:39 -0700, Chris Newman wrote: > While I'm less concerned than Mark about the difference in "blather" since > a good compression layer would largely fix that among many other "blather" > problems in IMAP/822/MIME/content The same argument ("it's just a compression problem") can be used against your claims of "non-scalability" of the existing top-level SORT and THREAD. Off hand, your proposed changes to VIEW commands and responses appear OK, with the important caveat that SORT and THREAD remain as top level commands. It is essential that it be possible to do a SORT or THREAD independent of the view. This is not "two ways of doing the same thing". One command returns sorted or threaded search results without altering the view. The other command sets the view and returns some subset of the results. Both are useful. Pine is likely to use both. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA26905 for ietf-imapext-bks; Thu, 24 Aug 2000 20:26:31 -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 UAA26901 for ; Thu, 24 Aug 2000 20:26:30 -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 UAA26573; Thu, 24 Aug 2000 20:27:04 -0700 (PDT) Received: from [192.129.100.100] (dsl198-113.Eng.Sun.COM [129.146.198.113]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA21928; Thu, 24 Aug 2000 20:27:03 -0700 (PDT) Date: Thu, 24 Aug 2000 20:24:01 -0700 From: Chris Newman To: Mark Crispin cc: IMAP Extensions WG Subject: re: Modularity vs. Protocol options Message-ID: <984785.3176137441@localhost> In-Reply-To: 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: When two extensions are completely separate, their impact on client complexity is separate. The more two extensions interact or perform similar functions, the more likely the client complexity they generate will be multiplicative. For example, SORT and THREAD are both functions to order the mailbox. If one can occur without the other, then the client's ordering user interface has to deal with 4 cases (neither, both, SORT only, THREAD only). The entire ordering interface has to be disabled or simulated in the first case. In the latter three, the ordering interface is enabled but in the latter two there are sub-cases which must be disabled or simulated. My conclusion is that, if possible, we should advertise both SORT and THREAD with the same capability (ORDER?) as that reduces client complexity. Is there any deployed server software which implements SORT and not _THREAD_ (or vice versa) and considers that a useful case to preserve in future versions? --On Thursday, August 24, 2000 16:50 -0700 Mark Crispin wrote: > Nevertheless, > SORT2 is not a separate "option", unless you consider RFC 1064, RFC 1176, > IMAP2bis, RFC 1730, and RFC 2060 as separate "options" of IMAP. Those are separate versions which is slightly better than separate options since older ones are likely to be deprecated. At this point it's quite practical to release IMAP software which only supports RFC 2060, which is a good thing since supporting maximum interoperability with all 5 variants is *a lot* of extra complexity. > What is more important is that these extensions are individually > additive, in keeping with the IMAP extensions model. Each extension > indicates the availability of a single feature. If the server does not > offer that feature, then the client is must do without it. >From a server's viewpoint, perhaps. From a GUI client viewpoint the extensions under discussion in this WG are options which interact in increasingly complex ways. That's one of the major reasons there is an imapext rather than a bunch of individual submissions. We need to minimize the complexity of the interactions between SORT/THREAD/VIEW/ACL/ANNOTATE and we can't push any of them forward until we've done a cursory evaluation of the interactions and determined we can deal. > If IMAPEXT were to accept Newman's argument, then it tear up all > extensions and disband, on the grounds that IMAP is impossible due to its > 2^19 "options", not to mention the 2^9 (or so) combinations of ways to > log in to the server. This is clearly absurd. I never said all extensions combine with multiplicative compexlity; only those with related functionality. The reason there is a WG is because we have rough concensus that the functionality added by the extensions we're considering is likely to be worth the cost of the complexity they introduce. But that does not justify introducing more complexity than necessary. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20499 for ietf-imapext-bks; Thu, 24 Aug 2000 19:39:40 -0700 (PDT) Received: from smtp4.andrew.cmu.edu (SMTP4.ANDREW.CMU.EDU [128.2.10.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20488 for ; Thu, 24 Aug 2000 19:39:38 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp4.andrew.cmu.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7P2e6g17020; Thu, 24 Aug 2000 22:40:06 -0400 Date: Thu, 24 Aug 2000 22:40:06 -0400 Message-Id: <200008250240.e7P2e6g17020@smtp4.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Mark Crispin Cc: IMAP Extensions WG , Chris Newman In-reply-to: Subject: Re: SORT, THREAD, and VIEW References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Wed, 23 Aug 2000 22:15:32 -0700 (PDT) From: Mark Crispin [...] By comparison, embedding THREAD and SORT into view, when output sorting is not desired, adds orders of magnitude more IMAP protocol blather. Compare: a1 SORT (SUBJECT) UTF-8 ALL * SORT 10 9 8 7 6 5 4 3 2 1 a1 OK done! with a2 VIEW SET SORT (SUBJECT) UTF-8 ALL * 10 EXISTS 10 a2 OK done! a3 VIEW FETCH 1:* VIEW (or just "tag FETCH 1:* VIEW") * 1 FETCH (VIEW 10) * 2 FETCH (VIEW 9) * 3 FETCH (VIEW 8) * 4 FETCH (VIEW 7) * 5 FETCH (VIEW 6) * 6 FETCH (VIEW 5) * 7 FETCH (VIEW 4) * 8 FETCH (VIEW 3) * 9 FETCH (VIEW 2) * 10 FETCH (VIEW 1) a3 OK done! I'm sorry, this example is somewhat bogus. Are you trying to simulate a client with a cache or without a cache? Without a cache (and with a virtual window size of 5, say), the protocol goes more like this: a1 SORT (SUBJECT) UTF-8 ALL * SORT 10 9 8 7 6 5 4 3 2 1 a1 OK done! a11 FETCH 10,9,8,7,6 (ENVELOPE) * 10 FETCH (ENVELOPE ...) * 9 FETCH (ENVELOPE ...) * 8 FETCH (ENVELOPE ...) * 7 FETCH (ENVELOPE ...) * 6 FETCH (ENVELOPE ...) a11 OK done! versus: a2 VIEW SET SORT (SUBJECT) UTF-8 AL * 10 EXISTS 10 a2 OK done! a3 VIEW FETCH 1:5 (ENVELOPE) * 10 FETCH (VIEW 1 ENVELOPE ...) * 9 FETCH (VIEW 2 ENVELOPE ...) * 8 FETCH (VIEW 3 ENVELOPE ...) * 7 FETCH (VIEW 4 ENVELOPE ...) * 6 FETCH (VIEW 5 ENVELOPE ...) a3 OK done! (Note that, of the two sessions above, the second can be pipelined and the first can't.) With a partial cache, it's not clear to me what the protocol looks like---I'm certainly unfamiliar enough with VIEW, and I suppose it depends whether latency, bandwidth, or some other quantity is your primary concern. With a full disconnected cache, there is no protocol---the client already has the necessary data and does the work. Larry Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA11446 for ietf-imapext-bks; Thu, 24 Aug 2000 18:13:54 -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 SAA11438 for ; Thu, 24 Aug 2000 18:13:47 -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 SAA04851 for ; Thu, 24 Aug 2000 18:14:19 -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 SAA17985 for ; Thu, 24 Aug 2000 18:14:18 -0700 (PDT) Date: Thu, 24 Aug 2000 18:12:39 -0700 From: Chris Newman To: IMAP Extensions WG Subject: Simplified VIEW strawman Message-ID: <629316.3176129559@nifty-jr.west.sun.com> In-Reply-To: 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've been putting some thought into VIEW and the interaction with the current SORT/THREAD. I'd like to draw people's attention to Mark's comment here: --On Wednesday, August 23, 2000 22:15 -0700 Mark Crispin wrote: > By comparison, embedding THREAD and SORT into view, when output sorting > is not desired, adds orders of magnitude more IMAP protocol blather. > Compare: a1 SORT (SUBJECT) UTF-8 ALL > * SORT 10 9 8 7 6 5 4 3 2 1 > a1 OK done! > with > a2 VIEW SET SORT (SUBJECT) UTF-8 ALL > * 10 EXISTS 10 > a2 OK done! > a3 VIEW FETCH 1:* VIEW (or just "tag FETCH 1:* VIEW") > * 1 FETCH (VIEW 10) > * 2 FETCH (VIEW 9) > * 3 FETCH (VIEW 8) > * 4 FETCH (VIEW 7) > * 5 FETCH (VIEW 6) > * 6 FETCH (VIEW 5) > * 7 FETCH (VIEW 4) > * 8 FETCH (VIEW 3) > * 9 FETCH (VIEW 2) > * 10 FETCH (VIEW 1) > a3 OK done! > > You are not going to convince me that the world is a better place for > having the latter forced upon those of us who are using the former with > great success today. While I'm less concerned than Mark about the difference in "blather" since a good compression layer would largely fix that among many other "blather" problems in IMAP/822/MIME/content, I'm much more concerned that there are two ways to do the same thing. If we standardize both of them, we have made a serious design error. The WG meeting rough concensus was to standardize *only* the latter model. But perhaps we could standardize only the former model after fixing the bugs/adding the missing features? Here's a simpler VIEW strawman based on the following assumptions: (1) caching across view changes is important -- this assumption largely breaks the current VIEW proposal. I'm told by client authors it is important so I'll trust that for now. The direct implication is that view position numbers should not be treated as a first-class key. (2) current SORT/THREAD result syntax should be preserved (3) Semi/full dynamic updates important (4) Scalability/windowing is important (5) K.I.S.S. I've broken this into functional groups -- SET, SEMI, FULL and WINDOW: ------ VIEW When no VIEW is active, a VIEW command must include "SET" or a "BAD" will result. VIEW with no arguments cancels the current view. VIEW with "SET" subcommand changes the view and returns WINDOW/SORT/THREAD results. VIEW without "SET" command applies to last view. The following VIEW modifiers are allowed: SET SEARCH/SORT/THREAD ... This changes the current VIEW and returns an untagged VIEW response (superset of SORT/THREAD/SEARCH response syntax). Must be at end of line. SEMI This causes the client to be notified of basic changes. A position of "0" in MOVE indicates outside the view. A newpos of "0" won't happen with SEMI -- messages don't leave the view except by expunge. * 2000 EXISTS tag VIEW SEMI SET SORT ... rest of sort command ... * VIEW ... ... * MOVE (oldpos newpos) (oldpos newpos) ... * 1 EXPUNGE * 2005 EXISTS (VIEW ...) The (VIEW ...) modifier to EXISTS result lists view positions of new messages. At this point I prefer extending EXPUNGE/EXISTS to keep the related data together. FULL Same as SEMI, but a newpos of "0" is permitted. WINDOW This returns a subrange of the result set from SEARCH/SORT/THREAD, and is necessary for scalability on the basis of mailbox size. tag VIEW WINDOW SORT ... rest of subcommand * VIEW WINDOW ... subset of SORT results tag VIEW WINDOW THREAD ... rest of subcommand * VIEW WINDOW (+n seqno seqno ...) seqno seqno (seqno seqno +n) tag VIEW WINDOW + THREAD ... rest of subcommand * VIEW WINDOW (+n seqno seqno ...) seqno (seqno +n) (seqno seqno +n) tag VIEW WINDOW (returns window data for new range from previous VIEW) If is true, results for all sub-threads will be included ( is ignored with SORT). Otherwise only results for the top level will be included. The + form is needed for expanded view (descend true) where the correct end can't be determined in advance by a client. The "+n" indicates that there were n messages in that sub-thread outside the WINDOW. ------ - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09459 for ietf-imapext-bks; Thu, 24 Aug 2000 17:11:46 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (warner@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09455 for ; Thu, 24 Aug 2000 17:11:45 -0700 (PDT) Date: Thu, 24 Aug 2000 16:50:33 -0700 (PDT) From: Mark Crispin Subject: re: Modularity vs. Protocol options To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <302707.3176124129@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 Thu, 24 Aug 2000 16:42:09 -0700, Chris Newman wrote: > If we follow the course Mark is promoting, we could end up with: > SORT > THREAD > SORT2 (with missing keys added and possible i18n fixes), > VIEW > That's 4 options, and since VIEW interacts with the other three, multiply > the above complexity list by at least 7. There are no "4 options", much less a multiplier factor of 7. Whether or not SORT is extended to SORT2 remains unsettled. Nevertheless, SORT2 is not a separate "option", unless you consider RFC 1064, RFC 1176, IMAP2bis, RFC 1730, and RFC 2060 as separate "options" of IMAP. SORT2 is nothing more than an extension. What is more important is that these extensions are individually additive, in keeping with the IMAP extensions model. Each extension indicates the availability of a single feature. If the server does not offer that feature, then the client is must do without it. If IMAPEXT were to accept Newman's argument, then it tear up all extensions and disband, on the grounds that IMAP is impossible due to its 2^19 "options", not to mention the 2^9 (or so) combinations of ways to log in to the server. This is clearly absurd. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09180 for ietf-imapext-bks; Thu, 24 Aug 2000 16:43:17 -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 QAA09176 for ; Thu, 24 Aug 2000 16:43:16 -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 QAA12689 for ; Thu, 24 Aug 2000 16:43:49 -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 QAA13370 for ; Thu, 24 Aug 2000 16:43:48 -0700 (PDT) Date: Thu, 24 Aug 2000 16:42:09 -0700 From: Chris Newman To: IMAP Extensions WG Subject: Modularity vs. Protocol options Message-ID: <302707.3176124129@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'm a huge supporter of modular design. Indeed, one reason I dislike object oriented languages is that a well designed modular program will often have several modules which operate on the same object, and most object oriented languages discourage or prohibit such good design. However, large numbers of protocol options are bad, and doubly so when they interact. Furthermore, two different ways to do the same thing is also bad. Every "option" results in the following complexity in every client: 1. a test for the presence of the option 2. facility to enable/disable all GUI elements impacted by that option 3. Adding conditionals to any commands which that option introduces 4. Adding an additional code path (with associated maintenance and bugs) if the option offers a performance enhancement. 5. If the option is sufficiently important to users, include all the code necessary to simulate the behavior of the option when it's not present. 6. Interop and regression tests related to the option must be done once against servers without it and again with the option. When options interact, then the complexity tends to be multiplicative. If we follow the course Mark is promoting, we could end up with: SORT THREAD SORT2 (with missing keys added and possible i18n fixes), VIEW That's 4 options, and since VIEW interacts with the other three, multiply the above complexity list by at least 7. IMHO, we should have a single extension name (how about "ORDER=thread-alg,...") which includes as much of the SORT/THREAD/VIEW functionality as we believe is ready for the standards track. I fully encourage implementors to write their code with the modular design that Mark explained, but there's no reason that design must be reflected in the capability list, and many reasons why it shouldn't. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA05698 for ietf-imapext-bks; Thu, 24 Aug 2000 14:10:48 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05692 for ; Thu, 24 Aug 2000 14:10:46 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 24 Aug 2000 14:08:02 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Aug 2000 14:08:28 -0700 (Pacific Daylight Time) Received: from DF-SPOT.platinum.corp.microsoft.com ([172.30.236.99]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 24 Aug 2000 14:08:31 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00E0F.74DDFDCB" Subject: RE: Microsoft Canards Date: Thu, 24 Aug 2000 14:08:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Microsoft Canards Thread-Index: AcAN83Q7OqTT2Rc9RIC9hs0EgxIsSgAGw/Zg From: "Larry Osterman" To: "Chris Newman" , "Mark Crispin" Cc: "IMAP Extensions WG" X-OriginalArrivalTime: 24 Aug 2000 21:08:31.0944 (UTC) FILETIME=[752B3C80:01C00E0F] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C00E0F.74DDFDCB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand that, it's just that that particular quote is one of my hot buttons - so very few people remember what the market was like back in 1982 (heck, there may be people reading this that weren't ALIVE back in 1982!) that it's easy to say "hee hee - wasn't Bill Gates (Mr. Bloatware himself) so stupid back then" - and that's how urban legends like this one get started. People forget that the original PC was a 4.77mhz 8088 with 64K of RAM, and that the base machine came with no floppy and two monitor choices: a display adapter that was capable of 640x480 in 4 colors, and 320x240 in 16 colors, and a black&white text-only display adapter. That was it, nothing else. It wasn't until '83 that PC's started coming with a floppy drive as a standard option. And in the world of the original PC, a 640K wasn't such a limitation - after all, a meg of RAM cost over a thousand dollars back then... Anyway, as I said - it's one of my personal hot buttons, so..... Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Platinum! Please notify the sender of any difficulties. > -----Original Message----- > From: Chris Newman [mailto:cnewman@innosoft.com] > Sent: Thursday, August 24, 2000 10:46 AM > To: Larry Osterman; Mark Crispin > Cc: IMAP Extensions WG > Subject: Re: Microsoft Canards >=20 >=20 > Very sorry, I must have misremembered the quote attribution. =20 > The point I=20 > was trying to make is that smart and famous people often fail=20 > to predict=20 > the requirements for the future. Thus designing for=20 > scalability rather=20 > than for "what works today" is usually well worth the effort. >=20 > - Chris >=20 >=20 ------_=_NextPart_001_01C00E0F.74DDFDCB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Microsoft Canards

I understand that, it's just that that particular = quote is one of my hot buttons - so very few people remember what the = market was like back in 1982 (heck, there may be people reading this = that weren't ALIVE back in 1982!) that it's easy to say "hee hee - = wasn't Bill Gates (Mr. Bloatware himself) so stupid back then" - = and that's how urban legends like this one get started.

People forget that the original PC was a 4.77mhz 8088 = with 64K of RAM, and that the base machine came with no floppy and two = monitor choices: a display adapter that was capable of 640x480 in 4 = colors, and 320x240 in 16 colors, and a black&white text-only = display adapter. That was it, nothing else. It wasn't until = '83 that PC's started coming with a floppy drive as a standard = option. And in the world of the original PC, a 640K wasn't such a = limitation - after all, a meg of RAM cost over a thousand dollars back = then...

Anyway, as I said - it's one of my personal hot = buttons, so.....

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 = and Outlook 2000 and Exchange Platinum! Please notify the sender = of any difficulties.

> -----Original Message-----
> From: Chris Newman [mailto:cnewman@innosoft.com]
> Sent: Thursday, August 24, 2000 10:46 AM
> To: Larry Osterman; Mark Crispin
> Cc: IMAP Extensions WG
> Subject: Re: Microsoft Canards
>
>
> Very sorry, I must have misremembered the quote = attribution.
> The point I
> was trying to make is that smart and famous = people often fail
> to predict
> the requirements for the future. Thus = designing for
> scalability rather
> than for "what works today" is usually = well worth the effort.
>
> = - Chris
>
>

------_=_NextPart_001_01C00E0F.74DDFDCB-- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03331 for ietf-imapext-bks; Thu, 24 Aug 2000 11:22:24 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (smj@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03327 for ; Thu, 24 Aug 2000 11:22:22 -0700 (PDT) Date: Thu, 24 Aug 2000 10:49:51 -0700 (PDT) From: Mark Crispin Subject: Re: Microsoft Canards To: Chris Newman cc: Larry Osterman , IMAP Extensions WG In-Reply-To: <646118.3176102782@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 Thu, 24 Aug 2000 10:46:22 -0700, Chris Newman wrote: > Very sorry, I must have misremembered the quote attribution. It was another individual, at a computer manufacturer which no longer exists, and the quote was that nobody would need a personal computer. The remnants of that company are now owned by a PC maker. > The point I > was trying to make is that smart and famous people often fail to predict > the requirements for the future. Thus designing for scalability rather > than for "what works today" is usually well worth the effort. Nevertheless, there is such a thing as extremism and pulling numbers out of nowhere with no supporting evidence. The history of Internet protocols is littered with good ideas that were irrepairably damaged by excessive zeal and rash speculation of future needs. How many people on this list actually have tested their implementations with 100,000 message mailboxes? I have, and have demonstrated that it works. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA03006 for ietf-imapext-bks; Thu, 24 Aug 2000 10:59:05 -0700 (PDT) Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03002 for ; Thu, 24 Aug 2000 10:59:03 -0700 (PDT) Received: from ken.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.0) with ESMTP id e7OHx5A25973; Thu, 24 Aug 2000 13:59:05 -0400 Message-ID: <39A56142.35BF4557@oceana.com> Date: Thu, 24 Aug 2000 13:54:10 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG CC: Mark Crispin Subject: Re: SORT, THREAD, and VIEW References: 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: Mark Crispin wrote: [...] > The current top-level SORT and THREAD always have had the capability to limit > the messages which are sorted (input subsetting). Input subsetting is what > controls the size of the "hunk". If that's what you're concerned about, you > belong on the top-level SORT/THREAD bandwagon; your problems are solved and > you might as well start writing code. > > This is not what VIEW does. VIEW does output subsetting; that is, subsetting > of the results of SEARCH/SORT/THREAD for transmission to the client. The > complete results are maintained on the server, so that the client can get > other subsets later on. > > Output subsetting happens after all the sorting is completed, since it is on > the results of the sort. You can't subset the output without first sorting > all candidate messages. You have no way of knowing, prior to sorting, which > messages will be in a particular subset of the results. > > Here's how they interoperate: > INPUT OPTIONAL OUTPUT > SUBSETTING -> ORDERING -> SUBSETTING > (SEARCH) (SORT/THREAD) (VIEW) > > Note that the ordering step is optional; VIEW SEARCH is an example of doing > output subsetting directly on input subsetting. > > The only thing mandatory is input subsetting. You have to do this, even if > it's just to say "all messages in the mailbox". Fortunately, it's a low-cost > operation to do it. > > The entire point of VIEW is to preserve the results of the "hunk" (the results > of input subsetting, optionally modified by ordering) so that the server can > get at pieces of the "hunk" readily to answer subsequent client requests > without having to do the underlying input subsetting and ordering over again. > > Another important aspect of VIEW is to announce to the client the impact of > new messages on the view. This also presupposes the server preserving the > "hunk". This is by far the best description that I've seen of how SEARCH/SORT/THREAD/VIEW are designed to operate. It has helped solidify my understanding of the various components and I think it can help others. Perhaps some of this text should make its way into the appropriate document(s)? > Embedding THREAD and SORT into VIEW creates a gigantic monolith that contains > the disjoint functionalities of sorting, threading, and windowing, each piece > of which depends upon all the others. It is impossible to extend any of these > functionalities without changing the entire monolith. This is not modular. > > The SEARCH specification does input subsetting. This is leveraged by the > current SORT/THREAD specifications, which orders the SEARCH results. > SORT/THREAD do not incorporate searching; instead, they use the searching > mechanism provided by SEARCH. An extension to SEARCH automatically extends > SORT/THREAD. A change to SORT/THREAD does not alter SEARCH. This is modular. > > The current VIEW specification does output subsetting. VIEW does not > incorporte ordering; instead, it uses the ordering functionality provided by > SORT/THREAD. An extension to SORT/THREAD automatically extends VIEW. A > change to VIEW does not alter SORT/THREAD or SEARCH. This is modular. Exactly. The point is that any component should be upgradable without affecting the other components. If scalability issues (real, not perceived) with SORT/THREAD arise, then they can be addressed independently of VIEW. That being said, I *might* be inclined to concede that toplevel SORT/THREAD might not scale well enough to handle 100,000 messages mailboxes on a handheld. However I would assert that toplevel SORT/THREAD is the wrong tool for the job. This application would be better served by VIEW. MORE IMPORTANTLY, I would also assert that VIEW is the wrong tool for a 10 message mailbox. The overhead on the server for setting up and maintaining the view is unnecessary, not to mention the wasted network bandwidth caused by the FETCHes. Toplevel SORT/THREAD is the right tool for this job. The mailbox size at which one solution becomes better than the other can be debated, but I think BOTH have their place and the choice of when to use them should be left to the client vendor. The modular approach suggested by Mark (separate SORT, THREAD and VIEW) allows both of these solutions to peacefully coexist which ultimately benefits everyone. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02915 for ietf-imapext-bks; Thu, 24 Aug 2000 10:47:25 -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 KAA02910 for ; Thu, 24 Aug 2000 10:47:24 -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 KAA09780; Thu, 24 Aug 2000 10:47:56 -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 KAA17201; Thu, 24 Aug 2000 10:47:55 -0700 (PDT) Date: Thu, 24 Aug 2000 10:46:22 -0700 From: Chris Newman To: Larry Osterman , Mark Crispin cc: IMAP Extensions WG Subject: Re: Microsoft Canards Message-ID: <646118.3176102782@nifty-jr.west.sun.com> In-Reply-To: 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: Very sorry, I must have misremembered the quote attribution. The point I was trying to make is that smart and famous people often fail to predict the requirements for the future. Thus designing for scalability rather than for "what works today" is usually well worth the effort. - Chris Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id CAA08747 for ietf-imapext-bks; Thu, 24 Aug 2000 02:14:45 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (resp@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08743 for ; Thu, 24 Aug 2000 02:14:43 -0700 (PDT) Date: Wed, 23 Aug 2000 22:15:32 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Pete Resnick cc: Chris Newman , IMAP Extensions WG 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 Thu, 24 Aug 2000 00:07:27 -0500, Pete Resnick wrote: > So, I expect that in the near future (if I am > provided with the tools), I will certainly have a single 100,000 > message mailbox in IMAP. We are certainly moving in that direction > with local-storage clients. There's a lot implied by "if I am provided with the tools". As matters stand, you'll have a hard time today finding a tool that handles a 1000 message mailbox well. > On a > locally indexed mailbox of 100,000 messages, I could write the code > to do this with ease. I cannot do this (in any efficient way) with > the current tools available to me in IMAP. Do you have that code for a locally index mailbox of 100,000 messages today? What makes you conclude that embedding SORT and THREAD into VIEW will make it possible to do it in IMAP? > The point you miss is that until servers implement it, client writers > (who are clearly foaming at the mouth for this technology) are stuck. This is all the more reason not to delay it any further by delaying proven solutions in favor of something that doesn't even have a prototype implementation yet. > There are comparatively few servers implementations out there > compared to client implementations, and even less of us are in your > enviable position of having control of the source code of one of the > widest deployed implementations of each. The server implementations which support SORT and THREAD are the most widely deployed servers. The same is true for the client. It is exceedingly simple to implement SORT and THREAD in the client. The only thing hard at the server end is to implement THREAD=REFERENCES. > SORT/THREAD will > be good enough for servers to provide most of the current crop of > clients (who are "grab all of the messages in this mailbox and > present them to the user" clients) with a "limping along" version of > these features, but will preclude certain kinds of clients from > getting implemented: The longer that "grab all the messages" clients > can limp along, the more likely the technology will become > entrenched, even if it is inferior. This argument doesn't wash. I doubt that any of the "grab all of the messages in this mailbox" clients would use SORT/THREAD. There's no point to doing so; it's downloaded all of the messages and can do whatever sorting or threading it wants locally. I've traced what these clients do in their use of IMAP; they are POP clients that babble IMAP. They don't even leverage the basic features of IMAP. I am not just a server implementor. I've written multiple independent client implementations. Most of the sophisticated IMAP clients use my code from the c-client library. I have some idea of how clients are written. > The corollary to the above scenario is that IMAP gets a bad wrap: In > a local-storage client, showing different views of huge mailstores is > fast and efficient; IMAP will be seen as slow and annoying by users > who want the same kinds of functionality on their IMAP clients. A different corollary is that I use a fast client which doesn't have these problems, and eschew slow clients that do things the wrong way. > We will get no operational experience with views. You won't get such operational experience by forcing it on people! Or, at least, you won't get the right kind of operational experience. > Agreed. That argues that we should tread carefully here and get > implementations of VIEW going so that we can figure out where the > warts are soon. Which in turn argues that top-level SORT and THREAD should progress. If you persist in the plan of forcing SORT/THREAD as part of VIEW, the result will be that VIEW will be rushed in order to address the pent-up demand for SORT and THREAD. The result will be a VIEW specification that sucks big time, and which we'll be stuck with forever because those pent-up implementations are now using it and will refuse to allow a change. My plan satisfies the pent-up demand for SORT/THREAD functionality now, and allows the careful design and implementation of VIEW. My plan does not preclude VIEW. My plan makes VIEW easier to design implement, by focusing its scope on the one specific task it needs to accomplish. My plan is supported by the people who have implemented SORT/THREAD today, and who not coincidentally are the only people who are doing anything about implementing VIEW today. Traditionally, working code has counted for more than votes in the IETF. I hope that has not changed. > Having a top-level SORT > or THREAD may be making the hunk so big as that it will not be > transferrable easily to another context; This is a red herring. Everything happens inside the server. If the server can handle the "hunk" in top-level SORT then it can handle it for VIEW. VIEW carves up the "hunks" prior to delivering them to the client. However, VIEW needs the entire "hunk" for scalability; otherwise there's no point to it. > it's always easier to > implement when you know that the context is "all of the messages in > this particular mailbox" instead of having to deal with a subsetting > operation in addition. Either I have horribly misinterpreted what you are saying, or you are horribly confused as to how SORT, THREAD, and VIEW work and interoperate. The current top-level SORT and THREAD always have had the capability to limit the messages which are sorted (input subsetting). Input subsetting is what controls the size of the "hunk". If that's what you're concerned about, you belong on the top-level SORT/THREAD bandwagon; your problems are solved and you might as well start writing code. This is not what VIEW does. VIEW does output subsetting; that is, subsetting of the results of SEARCH/SORT/THREAD for transmission to the client. The complete results are maintained on the server, so that the client can get other subsets later on. Output subsetting happens after all the sorting is completed, since it is on the results of the sort. You can't subset the output without first sorting all candidate messages. You have no way of knowing, prior to sorting, which messages will be in a particular subset of the results. Here's how they interoperate: INPUT OPTIONAL OUTPUT SUBSETTING -> ORDERING -> SUBSETTING (SEARCH) (SORT/THREAD) (VIEW) Note that the ordering step is optional; VIEW SEARCH is an example of doing output subsetting directly on input subsetting. The only thing mandatory is input subsetting. You have to do this, even if it's just to say "all messages in the mailbox". Fortunately, it's a low-cost operation to do it. The entire point of VIEW is to preserve the results of the "hunk" (the results of input subsetting, optionally modified by ordering) so that the server can get at pieces of the "hunk" readily to answer subsequent client requests without having to do the underlying input subsetting and ordering over again. Another important aspect of VIEW is to announce to the client the impact of new messages on the view. This also presupposes the server preserving the "hunk". > Embedding THREAD and SORT into VIEW guarantees > modularity since it must work in the context of both "the entire > mailbox" and "some subset of messages". This makes no sense either. The only thing that deals with the question of "the entire mailbox" vs. "some subset of messages" is input subsetting, which is already done as part of top-level SORT/THREAD. Embedding THREAD and SORT into VIEW forces all clients of sorting and threading to use VIEW, whether or not output subsetting is desired. Mandatory input subsetting in SORT and THREAD merely adds 10 octets (" UTF-8 ALL") to the command when that functionality is not desired; it otherwise has no ill effects. By comparison, embedding THREAD and SORT into view, when output sorting is not desired, adds orders of magnitude more IMAP protocol blather. Compare: a1 SORT (SUBJECT) UTF-8 ALL * SORT 10 9 8 7 6 5 4 3 2 1 a1 OK done! with a2 VIEW SET SORT (SUBJECT) UTF-8 ALL * 10 EXISTS 10 a2 OK done! a3 VIEW FETCH 1:* VIEW (or just "tag FETCH 1:* VIEW") * 1 FETCH (VIEW 10) * 2 FETCH (VIEW 9) * 3 FETCH (VIEW 8) * 4 FETCH (VIEW 7) * 5 FETCH (VIEW 6) * 6 FETCH (VIEW 5) * 7 FETCH (VIEW 4) * 8 FETCH (VIEW 3) * 9 FETCH (VIEW 2) * 10 FETCH (VIEW 1) a3 OK done! You are not going to convince me that the world is a better place for having the latter forced upon those of us who are using the former with great success today. It gets worse if you decide to use UIDs. We have UID SORT and UID THREAD. VIEW requires that you do "VIEW FETCH 1:* UID" or "UID FETCH 1:* VIEW" or perhaps "FETCH 1:* (VIEW UID)" (wow, three ways to do the same thing, a record!). Anyway, it will result in lots of * 1 FETCH (VIEW 10 UID 10230)" results. The benefit of using VIEW is exclusively in those cases where the more complex VIEW protocol to support the client's subset is smaller than what top-level will do to deliver the full "hunk". Such cases exist, and become more likely as the mailbox grows larger. But there are plenty of cases where VIEW is not the proper tool. There are more problems than just the excessive protocol blather caused by forcing the use of a subsetting mechanism when it isn't needed. There are also fundamental architectural problems. Embedding THREAD and SORT into VIEW creates a gigantic monolith that contains the disjoint functionalities of sorting, threading, and windowing, each piece of which depends upon all the others. It is impossible to extend any of these functionalities without changing the entire monolith. This is not modular. The SEARCH specification does input subsetting. This is leveraged by the current SORT/THREAD specifications, which orders the SEARCH results. SORT/THREAD do not incorporate searching; instead, they use the searching mechanism provided by SEARCH. An extension to SEARCH automatically extends SORT/THREAD. A change to SORT/THREAD does not alter SEARCH. This is modular. The current VIEW specification does output subsetting. VIEW does not incorporte ordering; instead, it uses the ordering functionality provided by SORT/THREAD. An extension to SORT/THREAD automatically extends VIEW. A change to VIEW does not alter SORT/THREAD or SEARCH. This is modular. > I do believe that standardizing THREAD > and SORT independent of VIEW does leave the possibility that we will > be stuck with a way of doing things that won't fit into VIEW. Please offer a specific scenario of how top-level SORT or THREAD, as currently specified, make it harder to implement VIEW. I believe that any such scenario is based upon a flawed understanding of how SORT, THREAD, and VIEW work. I am prepared to prove it. Top-level SORT and THREAD are proven designs, with production implementations in use for years. The alleged problems are disputed by all the implementors. VIEW (in any form) is not here yet. It is not likely to arrive for quite some time given the current discussion about redesigning it. There isn't even a prototype implementation of VIEW. Even though complete redesigns of VIEW have been proposed to address various problems (such as the chattiness noted above), none of those proposals require that SORT and THREAD be embedded in VIEW. There are no valid technical reasons given for why SORT and THREAD should be embedded in VIEW. There may be political reasons, but politics should not be the deciding factor. I understand that this is a complex topic, especially to folks who are reading the documents and haven't actually implemented any of this stuff. I'm asking you not to be taken in by specious claims that are in direct conflict with years of operational experience. The effects of a requirement that SORT and THREAD be embedded in VIEW are to delay standardized sorting and threading functionality to everybody for years to come, and to add needless complexity to client implementations that could otherwise use top-level SORT and THREAD. I don't think that you want this. If I can answer your questions or concerns about top-level SORT/THREAD satisfactorily, will you support their progress to standardization? Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id WAA28558 for ietf-imapext-bks; Wed, 23 Aug 2000 22:07:35 -0700 (PDT) Received: from episteme-software.com (resnick1.qualcomm.com [63.250.90.98]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28554 for ; Wed, 23 Aug 2000 22:07:31 -0700 (PDT) Received: from champdsl-25.mcleodusa.net (216.43.25.68) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1); Thu, 24 Aug 2000 00:07:30 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: References: X-Mailer: Eudora [Macintosh version 5.0b10-09.00] Date: Thu, 24 Aug 2000 00:07:27 -0500 To: Mark Crispin From: Pete Resnick Subject: Re: SORT, THREAD, and VIEW Cc: Chris Newman , IMAP Extensions WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Speaking as a group participant, not as chair.] On 8/23/00 at 2:00 PM -0700, Mark Crispin wrote: >The underlying assumptions in this claim are that: > 1) a user would want to deal browse through a flat object of 100,000 members > 2) the technology of palm devices will remain static > 3) the technology of radio will remain static. >None of these assumptions are valid. Assumption (1) is particularly absurd; >if it was valid, then why do we bother with non-INBOX mailboxes in IMAP! Nonsense. Assumption 1 is mistated. It is not that a user would want to browse through a flat object of 100,000 members; it is that a piece of client software would want to access a flat object of 100,000 members and allow the user to create different subsetted views of that data on different criteria. This is why you are seeing local-storage clients move toward either proprietary format databases or externally indexed collections of messages instead of flat text files: Users have so much mail now and so many ways of wanting to view it that permanently moving a single copy of a message into a particular file in a single hierarchical directory structure is not sufficient. One of those views of messages is likely to be "thread": I might want to have a virtual mailbox of a particular thread which might have 50 messages in it. Some number of those messages might also belong to a virtual mailbox of a particular annotation I have on a message. And it would be silly of me to split these messages up into different files; what I care about is the viewing criteria, not the underlying file storage mechanism. So, I expect that in the near future (if I am provided with the tools), I will certainly have a single 100,000 message mailbox in IMAP. We are certainly moving in that direction with local-storage clients. >Although the IMAP tools for browsing through mailboxes are good, there is a >messages/mailbox limit which has remained fairly constant even as IMAP servers >have become far more competant in handling large mailboxes. This limit is >established by the human user, not by hardware or impmentation. It is absolutely an implementation (or more to the point, a protocol) limitation. That I as a user can't deal with a serial list of 100,000 messages is not at issue. It's whether my client can present me with interesting subsets of such a mailbox in different views. On a locally indexed mailbox of 100,000 messages, I could write the code to do this with ease. I cannot do this (in any efficient way) with the current tools available to me in IMAP. >What harm does standardization SORT/THREAD do to you? > >There is no harm in standardizing SORT/THREAD to IMAP: > 1) if server-maintained views in IMAP are really important, then the VIEW > command will happen and be widely-implemented. The point you miss is that until servers implement it, client writers (who are clearly foaming at the mouth for this technology) are stuck. There are comparatively few servers implementations out there compared to client implementations, and even less of us are in your enviable position of having control of the source code of one of the widest deployed implementations of each. > 2) if SORT/THREAD are good enough, then the VIEW command won't happen or > won't be widely implemented. That's a misstatement of the claim. Point 2 is that SORT/THREAD will be good enough for servers to provide most of the current crop of clients (who are "grab all of the messages in this mailbox and present them to the user" clients) with a "limping along" version of these features, but will preclude certain kinds of clients from getting implemented: The longer that "grab all the messages" clients can limp along, the more likely the technology will become entrenched, even if it is inferior. We can all point to such experiences in this industry, both inside and outside of the IETF. The corollary to the above scenario is that IMAP gets a bad wrap: In a local-storage client, showing different views of huge mailstores is fast and efficient; IMAP will be seen as slow and annoying by users who want the same kinds of functionality on their IMAP clients. >Your concern seems to be that (2) would happen, and lead to a future crisis. >If future events (such a world where people routinely thread 100,000 message >mailboxes from a 4MB Palm via radio modem) demonstrate that server-maintained >views are essential, then nothing precludes the reintroduction of VIEW. The >benefit is that, this time, there would be actual operational experience. > >The result would be that the right specification of server-maintained views, >that addresses the actual needs, would happen. In the meantime, there would >be a great operational benefit from SORT/THREAD. It's a catch-22 though. We will not get to a time where people routinely thread 100,000 messages from a Palm because the technology is not available now on the server to make such a client even remotely plausible. What we will get is clients increasingly dependent on getting the entire list of messages from a mailbox because we continue to add commands which require that view of the world. We will get no operational experience with views. >The harm in adding ill-conceived server-based view functionality into >SORT/THREAD is that it is likely to be an albatross that sinks all sorting and >threading functionality. Agreed. That argues that we should tread carefully here and get implementations of VIEW going so that we can figure out where the warts are soon. >Some of the worst warts in Internet protocols were >attempts at solutions to problems that did not exist; when the real problem >was shown to exist, the earlier "solution" did not address it. The general problem, however, already does exist: We have a class of applications and functionality (small devices; "virtual mailbox" views) which cannot be addressed with current technology. We don't know for sure what the "real problem" is, though I think we have a pretty good idea. >It is for this reason that we use a modular design in which solutions address >a single problem. The claim is that you are not being modular enough. Modularity is not just about a single solution for a single problem; it's about making the hunks small enough so that a hunk can be reused and doesn't get specialized to solving a single problem only. Having a top-level SORT or THREAD may be making the hunk so big as that it will not be transferrable easily to another context; it's always easier to implement when you know that the context is "all of the messages in this particular mailbox" instead of having to deal with a subsetting operation in addition. Embedding THREAD and SORT into VIEW guarantees modularity since it must work in the context of both "the entire mailbox" and "some subset of messages". None of this is to say that we've got VIEW right. I don't know the answer to that question. But I do believe that standardizing THREAD and SORT independent of VIEW does leave the possibility that we will be stuck with a way of doing things that won't fit into VIEW. 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 UAA23098 for ietf-imapext-bks; Wed, 23 Aug 2000 20:22:43 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (pearl@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA23093 for ; Wed, 23 Aug 2000 20:22:42 -0700 (PDT) Date: Wed, 23 Aug 2000 20:16:21 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Hugh McIntyre cc: Chris Newman , IMAP Extensions WG 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 Wed, 23 Aug 2000 20:13:38 -0700 (PDT), Hugh McIntyre wrote: > There is a rather important difference here though in that if I perform a > search on a mailbox I'm probably hoping to only get 10-20 matching messages > back. While if I perform a sort then I'm normally going to get the whole > mailbox. That all depends upon what you ask. Note that SORT is SEARCH with extra arguments. The client has the ability to decide what messages it wants to sort. Note that the bandwidth consumed by SORT results is modest for typical sized user mailboxes. SORT results for a 1000 message mailbox is just 3900 bytes. I have not encountered many IMAP clients that don't crash when a mailbox grows to more than a few hundred messages. Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22998 for ietf-imapext-bks; Wed, 23 Aug 2000 20:13:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22994 for ; Wed, 23 Aug 2000 20:13:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA05544; Wed, 23 Aug 2000 21:13:40 -0600 (MDT) Received: from frantic.Eng.Sun.COM (frantic.Eng.Sun.COM [129.144.137.28]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA11353; Wed, 23 Aug 2000 20:13:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by frantic.Eng.Sun.COM (8.9.3+Sun/8.8.8) with SMTP id UAA28674; Wed, 23 Aug 2000 20:13:39 -0700 (PDT) Date: Wed, 23 Aug 2000 20:13:38 -0700 (PDT) From: Hugh McIntyre Reply-To: Hugh McIntyre Subject: Re: SORT, THREAD, and VIEW To: Mark Crispin Cc: Chris Newman , IMAP Extensions WG In-Reply-To: "Your message with ID" 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: (Without making any comment either way on the rest of the argument): |> The SEARCH response, which has been in IMAP from inception, is dependent on |> the size of the mailbox in the way you contend. SORT is nothing more than a |> SEARCH with alternate ordering of the results. There is a rather important difference here though in that if I perform a search on a mailbox I'm probably hoping to only get 10-20 matching messages back. While if I perform a sort then I'm normally going to get the whole mailbox. Hugh. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA17336 for ietf-imapext-bks; Wed, 23 Aug 2000 17:18:36 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA17332 for ; Wed, 23 Aug 2000 17:18:34 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 23 Aug 2000 17:17:54 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Aug 2000 17:18:23 -0700 (Pacific Daylight Time) Received: from DF-SPOT.platinum.corp.microsoft.com ([172.30.236.99]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Wed, 23 Aug 2000 17:17:44 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C00D60.B7015F7C" Subject: Microsoft Canards Date: Wed, 23 Aug 2000 17:17:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SORT, THREAD, and VIEW Thread-Index: AcANVyD8B9f/iOs5RziFVRhVSm004QACFZog From: "Larry Osterman" To: "Mark Crispin" , "Chris Newman" Cc: "IMAP Extensions WG" X-OriginalArrivalTime: 24 Aug 2000 00:17:44.0737 (UTC) FILETIME=[B98C3910:01C00D60] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C00D60.B7015F7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable And I gotta step in here. >=20 > > I'll also note that when Bill Gates said that 640K was more than any > > computer would ever need, that it was certainly more than I=20 > could imagine > > needing at the time. >=20 > This is irrelevant. Personal computers bigger than 640K=20 > existed before the > founding of Microsoft. Timesharing systems with 10MB or more=20 > also existed at > that time. Bill Gates NEVER said any such thing. In fact, one of the first products for the PC that Microsoft produced (the Microsoft SmartCard(tm) was a RAM expansion board that would allow you to bump the PC's base memory from 256K to 768K (in its most maxed out configuration). It also added features like a battery backed clock, since IBM didn't add one until the PC/AT (ok, the PC/jr had a built-in clock, but who counts the PC/jr?). The decision to limit the user defined RAM on the original PC was an IBM hardware design decision - they needed to reserve a portion of the 1M physical address space (the 808x could only address 1M of memory) for memory mapped hardware and ROM units. They decided that 640K (10 times the default memory configuration of 64K) was more than enough memory for what was intended as a game machine - don't forget - the floppy drive was an ADD-ON for the original PC, and a hard disk (10 meg!) didn't come until the PC/XT in 1982 (when IBM bumped the default memory to 256K). And don't forget that it was Steve Jobs who said that a properly designed machine would NEVER require more than 128K of RAM. He also said that a properly designed machine wouldn't need a cooling fan, that's why the original MAC would melt down if you put a piece of paper on top of it. Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Platinum! Please notify the sender of any difficulties. ------_=_NextPart_001_01C00D60.B7015F7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Microsoft Canards

And I gotta step in here.
>
> > I'll also note that when Bill Gates said = that 640K was more than any
> > computer would ever need, that it was = certainly more than I
> could imagine
> > needing at the time.
>
> This is irrelevant. Personal computers = bigger than 640K
> existed before the
> founding of Microsoft. Timesharing systems = with 10MB or more
> also existed at
> that time.

Bill Gates NEVER said any such thing. In fact, = one of the first products for the PC that Microsoft produced (the = Microsoft SmartCard(tm) was a RAM expansion board that would allow you = to bump the PC's base memory from 256K to 768K (in its most maxed out = configuration). It also added features like a battery backed = clock, since IBM didn't add one until the PC/AT (ok, the PC/jr had a = built-in clock, but who counts the PC/jr?).

The decision to limit the user defined RAM on the = original PC was an IBM hardware design decision - they needed to reserve = a portion of the 1M physical address space (the 808x could only address = 1M of memory) for memory mapped hardware and ROM units. They = decided that 640K (10 times the default memory configuration of 64K) was = more than enough memory for what was intended as a game machine - don't = forget - the floppy drive was an ADD-ON for the original PC, and a hard = disk (10 meg!) didn't come until the PC/XT in 1982 (when IBM bumped the = default memory to 256K).

And don't forget that it was Steve Jobs who said that = a properly designed machine would NEVER require more than 128K of = RAM. He also said that a properly designed machine wouldn't need a = cooling fan, that's why the original MAC would melt down if you put a = piece of paper on top of it.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 = and Outlook 2000 and Exchange Platinum! Please notify the sender = of any difficulties.

------_=_NextPart_001_01C00D60.B7015F7C-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA15979 for ietf-imapext-bks; Wed, 23 Aug 2000 16:07:23 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (cecil@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA15975 for ; Wed, 23 Aug 2000 16:07:22 -0700 (PDT) Date: Wed, 23 Aug 2000 14:00:01 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Chris Newman cc: IMAP Extensions WG In-Reply-To: <5021320.3176025571@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 Wed, 23 Aug 2000 13:19:31 -0700, Chris Newman wrote: > SORT and THREAD are blocked because there is a known scalability issue. There is no "known scalability issue". You claim that one exists, but that claim is not universally accepted. I reject it. At least three other individuals have rejected it. > A > couple years back we discussed a strawman to fix that problem without > waiting for VIEW: > SORT

... rest of sort command ... > * SORT ... subrange of sort response ... It was rejected for good reason. It is a solution to a problem that does not exist. It creates signficant new problems. It is inapplicable to THREAD (which is far more important than SORT). > With the possible exception of the EXPUNGE response, IMAP > network usage is not dependent on the size of the mailbox. The SEARCH response, which has been in IMAP from inception, is dependent on the size of the mailbox in the way you contend. SORT is nothing more than a SEARCH with alternate ordering of the results. > I'll also note that when Bill Gates said that 640K was more than any > computer would ever need, that it was certainly more than I could imagine > needing at the time. This is irrelevant. Personal computers bigger than 640K existed before the founding of Microsoft. Timesharing systems with 10MB or more also existed at that time. > Perhaps you're comfortable betting that 100,000 > messages is larger than a mailbox will ever be, but I'm not. We are not talking about a growth in technology, or in software. We are talking about what a human being will reasonably deal with as a single flat object. Specifically, you contend that a future user will have a flat mailbox containing 100,000 messages with no partitioning, and that such a user will use a current technology 4MB Palm device with a current technology radio modem to access it. The underlying assumptions in this claim are that: 1) a user would want to deal browse through a flat object of 100,000 members 2) the technology of palm devices will remain static 3) the technology of radio will remain static. None of these assumptions are valid. Assumption (1) is particularly absurd; if it was valid, then why do we bother with non-INBOX mailboxes in IMAP! Although the IMAP tools for browsing through mailboxes are good, there is a messages/mailbox limit which has remained fairly constant even as IMAP servers have become far more competant in handling large mailboxes. This limit is established by the human user, not by hardware or impmentation. Few IMAP clients work well beyond about 1000 messages; but I see the same limiting effects with clients that handle much larger mailboxes with aplomb. Our biggest mailbox users (a tiny minority) top off at about 5000-9000 messages per mailbox. I know from firsthand experience that Pine works well on a mailbox with 70,000 messages. The problem is that such a mailbox is overwhelming to the user. The user's first reaction is to break it up into more managable pieces. > So I will continue to actively oppose standardization of SORT/THREAD until > the defect is fixed either in the commands themselves or by combining them > with VIEW. What harm does standardization SORT/THREAD do to you? There is no harm in standardizing SORT/THREAD to IMAP: 1) if server-maintained views in IMAP are really important, then the VIEW command will happen and be widely-implemented. 2) if SORT/THREAD are good enough, then the VIEW command won't happen or won't be widely implemented. Either way, the problem is solved. Your concern seems to be that (2) would happen, and lead to a future crisis. If future events (such a world where people routinely thread 100,000 message mailboxes from a 4MB Palm via radio modem) demonstrate that server-maintained views are essential, then nothing precludes the reintroduction of VIEW. The benefit is that, this time, there would be actual operational experience. The result would be that the right specification of server-maintained views, that addresses the actual needs, would happen. In the meantime, there would be a great operational benefit from SORT/THREAD. I believe that there probably is a need for server-maintained views today. That is why I agreed to work on the VIEW specification. As specified today, SORT/THREAD do not preclude server-based views; and furthermore VIEW is designed with leverage of SORT/THREAD in mind. The harm in adding ill-conceived server-based view functionality into SORT/THREAD is that it is likely to be an albatross that sinks all sorting and threading functionality. Some of the worst warts in Internet protocols were attempts at solutions to problems that did not exist; when the real problem was shown to exist, the earlier "solution" did not address it. It is for this reason that we use a modular design in which solutions address a single problem. SORT/THREAD solve real problems that exist today. IMAP references threading is nearly two orders of magnitude more efficient than NNTP references threading. I have not heard any scalability arguments against standardization of the NNTP references threading mechanism. VIEW solves a problem that is speculated to exist. We don't know if the problem is real; nor do we have the operational experience to know that we have the right design for server-maintained views. Nevertheless, we are making a diligent effort at solving it, based upon a universal belief that server-maintained views are desirable. This effort would be enhanced by having the freedom to alter the VIEW design without impacting the existing, real-world, solutions to sorting and threading. It is bad design to bundle independent functionalities. It would be bad design to force server-maintained view functionality into the current independent search, sort, and thread functionalities. As long as these functionalities remain independent, we can tinker with server-maintained view functionality as needed without damaging the other functionalities. If, on the other hand, server-maintained view functionality is forced into the sorting and threading functionality, we are stuck with the implementation of that server-maintained view functionality. It will become impossible to change it in the future without also changing the sorting and threading functionality. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA13705 for ietf-imapext-bks; Wed, 23 Aug 2000 13:20:39 -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 NAA13701 for ; Wed, 23 Aug 2000 13:20:38 -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 NAA15190; Wed, 23 Aug 2000 13:21:05 -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 NAA23590; Wed, 23 Aug 2000 13:21:05 -0700 (PDT) Date: Wed, 23 Aug 2000 13:19:31 -0700 From: Chris Newman To: Mark Crispin cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <5021320.3176025571@nifty-jr.west.sun.com> In-Reply-To: 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: --On Friday, August 18, 2000 19:38 -0700 Mark Crispin wrote: > This discussion has convinced me that the concept of VIEW is still > extremely immature and must undergo experimentation (at least one > implementation!) before it is advanced. The pitfalls are not well > understood. That is a reasonable conclusion from this discussion. > The need for careful experimentation and testing of VIEW should not be > used to block advancement of SORT and THREAD. SORT and THREAD are > proven, available today, and working in production code. SORT and THREAD > are much simpler and can be deployed now. SORT and THREAD do not > preclude a viable VIEW specification; in fact, it would be relatively > simple to add VIEW to an implementation wthat uses SORT and THREAD. SORT and THREAD are blocked because there is a known scalability issue. A couple years back we discussed a strawman to fix that problem without waiting for VIEW: SORT

... rest of sort command ... * SORT ... subrange of sort response ... If you wish them to be standardized without VIEW, then add that fix (adjusting syntax as you wish) and you increase the chances significantly. It moves the scalability problem from a protocol design error to a server implementation detail. > The claims of "non-scalability" are still theoretical in nature only. > They have not been experienced by the existing implementations of SORT > and THREAD. On the contrary; SORT and THREAD are proven major performance > winners. I have never denied that SORT and THREAD are an improvement over unextended IMAP. But just because something is an improvement does not mean it is ready for standardization. A proposed standard is required to have no known defects. With the possible exception of the EXPUNGE response, IMAP network usage is not dependent on the size of the mailbox. It is a defect of SORT/THREAD that the performance of those commands depends on the size of the mailbox. I'll also note that when Bill Gates said that 640K was more than any computer would ever need, that it was certainly more than I could imagine needing at the time. Perhaps you're comfortable betting that 100,000 messages is larger than a mailbox will ever be, but I'm not. Indeed I'd like to see IMAP used more for permanent list archives and I'm sure there will be many lists which get more than 100,000 posts in their lifetime. So I will continue to actively oppose standardization of SORT/THREAD until the defect is fixed either in the commands themselves or by combining them with VIEW. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id UAA17347 for ietf-imapext-bks; Fri, 18 Aug 2000 20:01:23 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (clam@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA17343 for ; Fri, 18 Aug 2000 20:01:22 -0700 (PDT) Date: Fri, 18 Aug 2000 19:38:37 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Lawrence Greenfield cc: Cyrus Daboo , Steve Hubert , IMAP Extensions WG In-Reply-To: <200008190155.e7J1sxg12190@smtp4.andrew.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 18 Aug 2000 21:54:59 -0400, Lawrence Greenfield wrote: > Is there another advantage of fetching the full map besides the > ability to retain cached information? In the case of threads, you may want to know about the overall thread tree instead of just a piece of it. It will be quite difficult for many forms of thread interface to do something reasonable with less than the full tree. I don't know of any client which has done it. This discussion has convinced me that the concept of VIEW is still extremely immature and must undergo experimentation (at least one implementation!) before it is advanced. The pitfalls are not well understood. People are talking about radical changes to the design to answer objections; radical enough changes to require a complete review from the bottom up. I see no purpose for these radical changes other than to prevent the advancement of any means of sorting or threading that doesn't use VIEW. This is a not a good way to design a protocol. It is an excellent way to make serious mistakes. The need for careful experimentation and testing of VIEW should not be used to block advancement of SORT and THREAD. SORT and THREAD are proven, available today, and working in production code. SORT and THREAD are much simpler and can be deployed now. SORT and THREAD do not preclude a viable VIEW specification; in fact, it would be relatively simple to add VIEW to an implementation wthat uses SORT and THREAD. The claims of "non-scalability" are still theoretical in nature only. They have not been experienced by the existing implementations of SORT and THREAD. On the contrary; SORT and THREAD are proven major performance winners. The other argument that I've heard against advancing SORT and THREAD is a vague fear that, if standardized, SORT and THREAD would prove good enough; so there would no longer be an impetus to do anything about VIEW. That is not a valid argument. It is instead an argument to abandon the current specification of VIEW and start over. Put another way: if VIEW is really that weak, it deserves to die. This will give impetus to anyone who still wants it to come up with a stronger specification that will succeed. Received: by ns.secondary.com (8.9.3/8.9.3) id SAA11304 for ietf-imapext-bks; Fri, 18 Aug 2000 18:55:05 -0700 (PDT) Received: from smtp4.andrew.cmu.edu (SMTP4.ANDREW.CMU.EDU [128.2.10.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA11300 for ; Fri, 18 Aug 2000 18:55:04 -0700 (PDT) Received: from penguin.andrew.cmu.edu (PENGUIN.ANDREW.CMU.EDU [128.2.122.2]) by smtp4.andrew.cmu.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id e7J1sxg12190; Fri, 18 Aug 2000 21:55:00 -0400 Date: Fri, 18 Aug 2000 21:54:59 -0400 Message-Id: <200008190155.e7J1sxg12190@smtp4.andrew.cmu.edu> From: Lawrence Greenfield X-Mailer: BatIMail version 3.2 To: Cyrus Daboo , Steve Hubert Cc: IMAP Extensions WG In-reply-to: Subject: Re: SORT, THREAD, and VIEW References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Date: Fri, 18 Aug 2000 17:39:14 -0700 (PDT) From: Steve Hubert cc: IMAP Extensions WG Organization: University of Washington; Computing and Communications If the VIEW matches all the messages you're back to the O(n) problem. I can see where VIEW would be beneficial if done in conjunction with a SEARCH which limits the number of messages in the VIEW, but with SORT we are interested in all n messages. Either that, or you've got to do something like I was talking about using uids to paste VIEWs together so that the user doesn't know they are viewing only a subset. No! This is the crucial distinction with VIEW. You _don't_ narrow your VIEW to just the messages that fit on one page. You just fetch the messages that would fit on one page. For example: a000 SELECT INBOX .... * 3450 EXISTS a000 OK a001 VIEW SET SORT (SUBJECT) US-ASCII ALL * 3450 EXISTS 3450 a001 OK a002 VIEW FETCH 1:20 (ENVELOPE) * 43 FETCH (VIEW 1 ENVELOPE ...) * 23 FETCH (VIEW 2 ENVELOPE ...) ... client displays to user first twenty in sorted view ... a002 OK ... user scrolls a003 VIEW FETCH 21:40 (ENVELOPE) ... client displays to user the second twenty in sorted view ... * 87 FETCH (VIEW 21 ENVELOPE ...) ... a003 OK VIEW is useful _without_ narrowing. Notice in the example above the entire 3450 message map was never fetched. I think the flaw found in this conversation is that at this point in the protocol the client has fetched information about 40 messages scattered throughout the mailbox (43, 23, and 87, for instance). If the client changes VIEW now (say the user wants to see messasges sorted by sender) it would be good for the client to be able to use that cached information. Is there another advantage of fetching the full map besides the ability to retain cached information? Larry Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05438 for ietf-imapext-bks; Fri, 18 Aug 2000 17:39:19 -0700 (PDT) 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 RAA05434 for ; Fri, 18 Aug 2000 17:39:18 -0700 (PDT) Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id RAA10634; Fri, 18 Aug 2000 17:39:17 -0700 Received: from localhost (hubert@localhost) by shiva2.cac.washington.edu (8.10.1+UW00.04/8.10.1+UW00.04) with ESMTP id e7J0dFX23244; Fri, 18 Aug 2000 17:39:16 -0700 Date: Fri, 18 Aug 2000 17:39:14 -0700 (PDT) From: Steve Hubert To: Cyrus Daboo cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW In-Reply-To: <3513213.3175618741@socrates.cyrusoft.com> Message-ID: Organization: University of Washington; Computing and Communications 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, 18 Aug 2000, Cyrus Daboo wrote: > --On Friday, August 18, 2000 4:50 PM -0700 Steve Hubert > wrote: > > > The user wants to view the entire mailbox, though they are only looking at > > a page at a time, so perhaps the VIEW would be a single page of the sort > > results. > > No - you would do a VIEW that matches all the messages in the mailbox but > sets the sort order to whatever is required. Then you access each message > via view position numbers. The client will 'cache' messages as needed for > its display as the user scrolls their window. This is 'virtual scrollbars' > as opposed to 'paging'. If the VIEW matches all the messages you're back to the O(n) problem. I can see where VIEW would be beneficial if done in conjunction with a SEARCH which limits the number of messages in the VIEW, but with SORT we are interested in all n messages. Either that, or you've got to do something like I was talking about using uids to paste VIEWs together so that the user doesn't know they are viewing only a subset. I agree that you would typically set the VIEW to be all of the messages in this case in order to avoid some of the additional complexity that VIEW adds. Steve Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05355 for ietf-imapext-bks; Fri, 18 Aug 2000 17:32:57 -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 RAA05351 for ; Fri, 18 Aug 2000 17:32:55 -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 RAA03101; Fri, 18 Aug 2000 17:32:58 -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 RAA02719; Fri, 18 Aug 2000 17:32:57 -0700 (PDT) Date: Fri, 18 Aug 2000 17:31:38 -0700 From: Chris Newman To: Cyrus Daboo , IMAP Extensions WG Subject: Re: VIEW too chatty Message-ID: <1895727.3175608698@nifty-jr.west.sun.com> In-Reply-To: <3223946.3175613932@socrates.cyrusoft.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 18:58 -0400 Cyrus Daboo wrote: > I think the proposed windowing mechanism would be too drastic and > complicated a change to VIEW. Agreed. I was having too much fun. :-) However, I will note the windowing mechanism included a solution to the "Client needs VIEW map" problem. We probably still need something like: tag VIEW MAP

* VIEW MAP

: ... or for threaded views: * VIEW MAP (+n ...) ... ( +n) > There is a radical solution to this (probably too radical for most > people): allow the meaning of the numbers at the start of 'message-data' > responses to be either a sequence number, a view position number or a UID > depending on what the client wants. Thus a client that only cares about > UIDs would switch server responses to UIDS: > > a SELECT INBOX (RESPOND UID) <- tell server to use UIDs in responses > ... > > * 21345 FETCH ... <- 21345 is the message UID not sequence > number * 21346 EXPUNGE <- 21346 is a UID > > The same could be done for view position numbers. That way a client that > prefers the view position number can tell the server to always send it, > without the overhead of the additional response. I'll need to think about this some more. It might be better as a separate extension, since it's useful without VIEW. I'll observe a simpler solution to the specific problem would be to return VIEW position numbers only when explicitly requested. In other words, VIEW FETCH ... doesn't return the VIEW position number unless the ... includes a VIEW fetch item. >> (4) Verbosity of "* VIEW" responses when many messages added. > > Right now we have a * VIEW for each change. We could compress this down > to a single * VIEW for all changes during the command in progress. > Something along the lines off: > > * VIEW (1:3,5) (10 11 15 16) (1:2,20) > > The three groups represent: > > 1) View positions of messages removed from the view > 2) Pairs of view positions for messages moving in the view > 3) View positions of new messages added to the view I like this. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05087 for ietf-imapext-bks; Fri, 18 Aug 2000 17:17:16 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05083 for ; Fri, 18 Aug 2000 17:17:15 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id UAA05338; Fri, 18 Aug 2000 20:16:23 -0400 (EDT) Date: Fri, 18 Aug 2000 20:19:01 -0400 From: Cyrus Daboo To: Steve Hubert cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <3513213.3175618741@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 4:50 PM -0700 Steve Hubert wrote: > I guess my question is what happens when the user scrolls out of the VIEW. You can never 'scroll' out of the view. The view defines the set of messages that the user can see at any one time, though not all of those messages may be cached. Thus the view position number range defines the scroll range. > The user wants to view the entire mailbox, though they are only looking at > a page at a time, so perhaps the VIEW would be a single page of the sort > results. No - you would do a VIEW that matches all the messages in the mailbox but sets the sort order to whatever is required. Then you access each message via view position numbers. The client will 'cache' messages as needed for its display as the user scrolls their window. This is 'virtual scrollbars' as opposed to 'paging'. > In the top-level SORT case, we would just fetch the data we need > based on the sort map we've already gotten from the server. In the > integrated SORT/VIEW case we have to establish a new VIEW and ask the > server to sort again, no? We'll also have to use uids somehow to place the > "cursor" on the same current message and paste the old and new views > together, since the view sequence numbers won't tell us anything about > that. If we wish to cache results of the fetches we'll have to get uids > and cache based on uid and we'll have to map back and forth between view > numbers and uids. Am I thinking about it correctly, is that the way it is > designed to be used? View clients will need a map if they don't want to refetch messages they might already have when resetting a view (or initiating a view in the case of a disconnected client). But they don't need to get the whole map, only the part of the map for the messages actually visible to the user is required. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id RAA04894 for ietf-imapext-bks; Fri, 18 Aug 2000 17:07:34 -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 RAA04890 for ; Fri, 18 Aug 2000 17:07:33 -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 RAB24730; Fri, 18 Aug 2000 17:07:35 -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 RAA00708; Fri, 18 Aug 2000 17:07:32 -0700 (PDT) Date: Fri, 18 Aug 2000 17:06:13 -0700 From: Chris Newman To: Steve Hubert , IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <1803970.3175607173@nifty-jr.west.sun.com> In-Reply-To: X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 15:04 -0700 Steve Hubert wrote: > As a client developer (pine) one of the things I hope for in extensions is > simplicity. We already have two ways to refer to messages, uids and > sequence numbers. I don't want to have to keep track of a third. You already do, when you pull down SORT results. > The last proposed solution to the problem made my skin go pale. Sorry 'bout that. I know it was too complex, I was just having too much fun :-) > While I've got you, could someone explain how VIEW would be used to allow > a user to sort a mailbox and then scroll through it? How would you do this > so that it was snappy and didn't have the O(n) problem? Thanks. How do you do scalable windowing on an unsorted IMAP mailbox? You fetch information in sub-ranges by seqno. With a SORTed mailbox you use VIEW the same way -- do the VIEW SET SORT and fetch information in sub-ranges by view position. Even better, you get notified where new messages go in your view and don't have to re-issue the SORT command (wasting a round-trip and O(n) network bandwidth) for every new delivery. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id RAA04828 for ietf-imapext-bks; Fri, 18 Aug 2000 17:05:06 -0700 (PDT) Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA04824 for ; Fri, 18 Aug 2000 17:05:05 -0700 (PDT) Received: from ppp4.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.0) with ESMTP id e7J04YA04884; Fri, 18 Aug 2000 20:04:34 -0400 Message-ID: <399DCF96.B11E2BBB@oceana.com> Date: Fri, 18 Aug 2000 20:06:46 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Chris Newman CC: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW References: <1395622.3175600383@nifty-jr.west.sun.com> 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: Chris Newman wrote: > > --On Friday, August 18, 2000 16:54 -0400 Ken Murchison > wrote: > > Assuming that VIEW+SORT/THREAD is VIEW with embedded SORT/THREAD: > > > > I wasn't looking for a comparison of VIEW+SORT/THREAD vs. toplevel > > SORT/THREAD. I was looking for a comparison of VIEW+SORT/THREAD vs. > > VIEW which uses toplevel SORT/THREAD (ie, in the same manner that VIEW > > will use toplevel SEARCH). Specifically, will the embedded SORT/THREAD > > do some magical handwaving that would make it technically superior to a > > (potentially revised) toplevel SORT/THREAD? > > If I understand your question, you're asking for the technical difference > between a VIEW command which has extensible subcommands and a VIEW command > which has extensible subcommands which must also be top-level commands. > > The technical difference is that the latter requires the presence of a > top-level command, even if that top-level command wouldn't be useful. Putting aside any philosophical differences over whether toplevel SORT/THREAD is useful: In a back-asswards way I was attempting to get a consensus that the toplevel SORT/THREAD (with whatever additional sort keys and threading algorithms a deemed necessary) *could* be used with VIEW to perform the desired functions. If it turns out that the embedded SORT/THREAD would be so technically different or superior that toplevel SORT/THREAD couldn't be used, then we could short-circuit a lot of this discussion right now. I don't think this is the case, but want to see if anybody does. I'm fairly confident that a single SORT/THREAD engine in a server can be used for both VIEW and toplevel commands. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp Received: by ns.secondary.com (8.9.3/8.9.3) id QAA04356 for ietf-imapext-bks; Fri, 18 Aug 2000 16:50:47 -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 QAA04348 for ; Fri, 18 Aug 2000 16:50:46 -0700 (PDT) Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id QAA25552; Fri, 18 Aug 2000 16:50:42 -0700 Received: from localhost (hubert@localhost) by shiva2.cac.washington.edu (8.10.1+UW00.04/8.10.1+UW00.04) with ESMTP id e7INofi21729; Fri, 18 Aug 2000 16:50:42 -0700 Date: Fri, 18 Aug 2000 16:50:40 -0700 (PDT) From: Steve Hubert To: Cyrus Daboo cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW In-Reply-To: <3161821.3175612899@socrates.cyrusoft.com> Message-ID: Organization: University of Washington; Computing and Communications 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, 18 Aug 2000, Cyrus Daboo wrote: > The O(n) problem only comes with the SORT response. Once the client has the > SORT map, or has initiated a view, the set of commands it issues will > effectively be the same, i.e. at that point it is just filling its message > cache with messages in sorted order in response to user scroll actions. For > view clients this is done by using VIEW FETCH with ranges of view position > numbers (1:10 then 11:20 etc). For SORT clients, they have to use the > sorted sequence or UID numbers. In both cases the client gets only what it > needs, except for the SORT response which returns the entire map. I guess my question is what happens when the user scrolls out of the VIEW. The user wants to view the entire mailbox, though they are only looking at a page at a time, so perhaps the VIEW would be a single page of the sort results. In the top-level SORT case, we would just fetch the data we need based on the sort map we've already gotten from the server. In the integrated SORT/VIEW case we have to establish a new VIEW and ask the server to sort again, no? We'll also have to use uids somehow to place the "cursor" on the same current message and paste the old and new views together, since the view sequence numbers won't tell us anything about that. If we wish to cache results of the fetches we'll have to get uids and cache based on uid and we'll have to map back and forth between view numbers and uids. Am I thinking about it correctly, is that the way it is designed to be used? Steve Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02953 for ietf-imapext-bks; Fri, 18 Aug 2000 15:57:08 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02949 for ; Fri, 18 Aug 2000 15:57:07 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA05139; Fri, 18 Aug 2000 18:56:10 -0400 (EDT) Date: Fri, 18 Aug 2000 18:58:52 -0400 From: Cyrus Daboo To: Chris Newman , IMAP Extensions WG Subject: Re: VIEW too chatty Message-ID: <3223946.3175613932@socrates.cyrusoft.com> In-Reply-To: <802267.3175590518@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.1.0d1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 12:28 PM -0700 Chris Newman wrote: > There seems to be agreement that VIEW is too chatty. So perhaps we > should fix that _before_ we deploy it. Here are some "chatiness" > problems with the current VIEW proposal which can't be solved by a > general purpose compression layer: I think the proposed windowing mechanism would be too drastic and complicated a change to VIEW. There are other things we can do to the existing responses to make them less chatty. Here are some examples: > (1) Untagged VIEW responses for messages the client doesn't care about. Given that a server can send unsolicted FETCH's for messages a client is not interested in anyway, I think the overhead of this is not as bad as you might think. Particularly if my solution to (4) is used. > (2) Inclusion of VIEW position in FETCH responses even if the client has > the resources to cache that information. There is a radical solution to this (probably too radical for most people): allow the meaning of the numbers at the start of 'message-data' responses to be either a sequence number, a view position number or a UID depending on what the client wants. Thus a client that only cares about UIDs would switch server responses to UIDS: a SELECT INBOX (RESPOND UID) <- tell server to use UIDs in responses ... * 21345 FETCH ... <- 21345 is the message UID not sequence number * 21346 EXPUNGE <- 21346 is a UID The same could be done for view position numbers. That way a client that prefers the view position number can tell the server to always send it, without the overhead of the additional response. > (4) Verbosity of "* VIEW" responses when many messages added. Right now we have a * VIEW for each change. We could compress this down to a single * VIEW for all changes during the command in progress. Something along the lines off: * VIEW (1:3,5) (10 11 15 16) (1:2,20) The three groups represent: 1) View positions of messages removed from the view 2) Pairs of view positions for messages moving in the view 3) View positions of new messages added to the view This removes both UIDs and sequence numbers from the original * VIEW response. > (5) Inclusion of UIDs in VIEW/EXPUNGE responses even if the client > doesn't use UIDs. My suggestions for (4) takes care of VIEW, and the 'radical' suggestion for (2) takes care of EXPUNGE! -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02618 for ietf-imapext-bks; Fri, 18 Aug 2000 15:40:04 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02614 for ; Fri, 18 Aug 2000 15:40:03 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id SAA05105; Fri, 18 Aug 2000 18:38:57 -0400 (EDT) Date: Fri, 18 Aug 2000 18:41:39 -0400 From: Cyrus Daboo To: Steve Hubert , IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <3161821.3175612899@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 3:04 PM -0700 Steve Hubert wrote: > If we could keep the VIEW extension as orthogonal as possible to the SORT > and THREAD extensions we would solve real-world problems now in a > straight-forward way, and leave the mega-mailbox problem solving separate. > I'm strongly in favor of decoupling SORT and THREAD from VIEW so that they > may be used without having to invoke the VIEW machinery. The SORT extension as it stands only provides a static sort. When new messages arrive the client has to re-issue the sort command. Similarly when message state changes the client would have to reissue the sort to see whether the message moved or dropped our of view (assuming the search criteria was used with SORT). VIEW, on the other hand, provides for static, semi-dynamic or fully dynamic updates from the server (depending on how the client uses the \VIEW flag), without the need to get the full map each time. There are situations where this will be more efficient than getting the map. There are other situations where the map will be more efficient, at least based on the current 'chatty' view design. > While I've got you, could someone explain how VIEW would be used to allow > a user to sort a mailbox and then scroll through it? How would you do this > so that it was snappy and didn't have the O(n) problem? Thanks. The O(n) problem only comes with the SORT response. Once the client has the SORT map, or has initiated a view, the set of commands it issues will effectively be the same, i.e. at that point it is just filling its message cache with messages in sorted order in response to user scroll actions. For view clients this is done by using VIEW FETCH with ranges of view position numbers (1:10 then 11:20 etc). For SORT clients, they have to use the sorted sequence or UID numbers. In both cases the client gets only what it needs, except for the SORT response which returns the entire map. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02201 for ietf-imapext-bks; Fri, 18 Aug 2000 15:14:22 -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 PAA02197 for ; Fri, 18 Aug 2000 15:14:21 -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 PAA12678; Fri, 18 Aug 2000 15:14:23 -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 PAA22785; Fri, 18 Aug 2000 15:14:23 -0700 (PDT) Date: Fri, 18 Aug 2000 15:13:03 -0700 From: Chris Newman To: Ken Murchison cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <1395622.3175600383@nifty-jr.west.sun.com> In-Reply-To: <399DA299.D0EDCFEB@oceana.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 16:54 -0400 Ken Murchison wrote: > Assuming that VIEW+SORT/THREAD is VIEW with embedded SORT/THREAD: > > I wasn't looking for a comparison of VIEW+SORT/THREAD vs. toplevel > SORT/THREAD. I was looking for a comparison of VIEW+SORT/THREAD vs. > VIEW which uses toplevel SORT/THREAD (ie, in the same manner that VIEW > will use toplevel SEARCH). Specifically, will the embedded SORT/THREAD > do some magical handwaving that would make it technically superior to a > (potentially revised) toplevel SORT/THREAD? If I understand your question, you're asking for the technical difference between a VIEW command which has extensible subcommands and a VIEW command which has extensible subcommands which must also be top-level commands. The technical difference is that the latter requires the presence of a top-level command, even if that top-level command wouldn't be useful. - Chris Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02030 for ietf-imapext-bks; Fri, 18 Aug 2000 15:04:27 -0700 (PDT) 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 PAA02026 for ; Fri, 18 Aug 2000 15:04:26 -0700 (PDT) Received: from shiva2.cac.washington.edu (shiva2.cac.washington.edu [140.142.100.202]) by mxout1.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW99.09) with ESMTP id PAA27327 for ; Fri, 18 Aug 2000 15:04:27 -0700 Received: from localhost (hubert@localhost) by shiva2.cac.washington.edu (8.10.1+UW00.04/8.10.1+UW00.04) with ESMTP id e7IM4PD16804 for ; Fri, 18 Aug 2000 15:04:26 -0700 Date: Fri, 18 Aug 2000 15:04:19 -0700 (PDT) From: Steve Hubert To: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW In-Reply-To: Message-ID: Organization: University of Washington; Computing and Communications 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: As a client developer (pine) one of the things I hope for in extensions is simplicity. We already have two ways to refer to messages, uids and sequence numbers. I don't want to have to keep track of a third. If all I want to do is sort a mailbox and let the user scroll through it, I don't want to have to jump through several layers of indirection and complexity to do that. The last proposed solution to the problem made my skin go pale. There is an enormous amount of complexity there to solve a problem that we have yet to run into in real life. If we could keep the VIEW extension as orthogonal as possible to the SORT and THREAD extensions we would solve real-world problems now in a straight-forward way, and leave the mega-mailbox problem solving separate. I'm strongly in favor of decoupling SORT and THREAD from VIEW so that they may be used without having to invoke the VIEW machinery. While I've got you, could someone explain how VIEW would be used to allow a user to sort a mailbox and then scroll through it? How would you do this so that it was snappy and didn't have the O(n) problem? Thanks. -- Steve Hubert Pine Team, Univ. of Washington, Seattle Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01913 for ietf-imapext-bks; Fri, 18 Aug 2000 15:00:30 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01905 for ; Fri, 18 Aug 2000 15:00:27 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA05043; Fri, 18 Aug 2000 17:59:27 -0400 (EDT) Date: Fri, 18 Aug 2000 18:02:06 -0400 From: Cyrus Daboo To: Mark Crispin cc: Ken Murchison , Chris Newman , IMAP Extensions WG Subject: VIEW and THREAD, was Re: SORT, THREAD, and VIEW Message-ID: <3019107.3175610526@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0d1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Friday, August 18, 2000 2:39 PM -0700 Mark Crispin wrote: >> THREAD is a much more complicated issue. The way VIEW is designed now it >> allows hierarchical view position numbers > > THREAD is also completely hierarchical. > > If anything, VIEW doesn't quite handle threads very well, because it > tends to encourage an assumption of a flat view identifier space even > though threads are not flat. We have left the view position number syntax open so that we can have hierarchical view position numbers, e.g. '1.2', '2.4.5' etc. Isn't that enough to express hierarchy? The problem comes in ensuring that clients can specify ranges of hierarchy when doing fetches, but I think that's doable. e.g. VIEW FETCH 1:10 - fetch the first message at the top of the first ten threads VIEW FETCH 1.1:1.% - fetch all of the messages one level down in the first thread VIEW FETCH 1.1:1.%.% - fetch all of the messages in the first two levels down in the first thread VIEW FETCH 1,1.1:1.* - fetch all messages in the first thread The other problem comes in letting clients know when there are sub-hierarchies in each thread and how many messages there are in the sub-hierarchy. A fetch data item 'THREAD ' would work. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01637 for ietf-imapext-bks; Fri, 18 Aug 2000 14:41:56 -0700 (PDT) Received: from Tomobiki-Cho.CAC.Washington.EDU (noodle@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01633 for ; Fri, 18 Aug 2000 14:41:55 -0700 (PDT) Date: Fri, 18 Aug 2000 14:39:49 -0700 (PDT) From: Mark Crispin Subject: Re: SORT, THREAD, and VIEW To: Cyrus Daboo cc: Ken Murchison , Chris Newman , IMAP Extensions WG In-Reply-To: <2898802.3175608526@socrates.cyrusoft.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, 18 Aug 2000 17:28:46 -0400, Cyrus Daboo wrote: > THREAD is a much more complicated issue. The way VIEW is designed now it > allows hierarchical view position numbers THREAD is also completely hierarchical. If anything, VIEW doesn't quite handle threads very well, because it tends to encourage an assumption of a flat view identifier space even though threads are not flat. Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01510 for ietf-imapext-bks; Fri, 18 Aug 2000 14:27:05 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01502 for ; Fri, 18 Aug 2000 14:27:03 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id RAA04985; Fri, 18 Aug 2000 17:26:07 -0400 (EDT) Date: Fri, 18 Aug 2000 17:28:46 -0400 From: Cyrus Daboo To: Ken Murchison , Chris Newman cc: IMAP Extensions WG Subject: Re: SORT, THREAD, and VIEW Message-ID: <2898802.3175608526@socrates.cyrusoft.com> In-Reply-To: <399DA299.D0EDCFEB@oceana.com> X-Mailer: Mulberry/2.1.0d1 (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: