Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28070 for ietf-imapext-bks; Fri, 22 Dec 2000 22:56:50 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28063 for ; Fri, 22 Dec 2000 22:56:48 -0800 (PST) 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+UW00.01) with ESMTP id XAA18902; Fri, 22 Dec 2000 23:00:09 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (dlg@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 XAA26378; Fri, 22 Dec 2000 23:00:09 -0800 Date: Fri, 22 Dec 2000 22:38:02 -0800 (PST) From: Mark Crispin Subject: re: SORT wish list To: Cyrus Daboo cc: IMAP Extensions WG In-Reply-To: <3000526.977141407@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: Cyrus - The only one of your proposed new criteria that I really worry about is PARTS, since that requires obtaining the body structure. Unless it is cached, this represents a much more expensive operation than the others, which are either in fast meta-data (INTERNALDATE, FLAGS, RFC822.SIZE) or the RFC822 header (and likely the envelope). The implementation is straightforward enough, but getting it to finish before the sun novas is a different matter. Here's my comments, such as they are, about the other suggestions: FLAGS has an arguable use. I don't think that, by itself, it justifies creating SORT2; but it should certainly be part of SORT2 if it happens. Adding something like UID, as noted earlier, is a no-brainer. However, there is one problem with that UID acts as a terminal criterion; no criterion may follow it or they'll be ignored. A way around this would be to allow REVERSE as the final criterion to affect the implicit reverse sequence, e.g. REVERSE SUBJECT REVERSE. SENDER and REPLYTO aren't reasonably implementable with NNTP overviews (which is a concern in my implementation since one of the mail stores I can export is an NNTP-accessed newsgroup). Then again, neither are TO and CC; and I just issue an error message saying "you can't do that" for those. So there's a precedent... CORRESPONDENT has the same problem with overviews as SENDER/REPLYTO, plus it requires some mechanism for the server to learn about "aliases" to the user's email address. Actually, since the server only knows the login identifier and that doesn't have any necessary correspondence to the email address, there needs to be a means to identify the user's email address! This idea is a good one, but as it currently stands it is half-baked. IMHO, it may be the feature that is make/break for SORT2, so I recommend that you give some thought to it. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27391 for ietf-imapext-bks; Fri, 22 Dec 2000 22:34:36 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27375 for ; Fri, 22 Dec 2000 22:34:32 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id WAA13556; Fri, 22 Dec 2000 22:37:53 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (ccx@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 WAA25983; Fri, 22 Dec 2000 22:37:53 -0800 Date: Fri, 22 Dec 2000 22:23:45 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison In-Reply-To: <5568138.977229781@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 Tue, 19 Dec 2000 12:43:01 -0500, Cyrus Daboo wrote: > Its not so much that I'm confused, but rather suprised by the fact the > client ends up having to do some of the sort work for the reversal case. Well, given that many clients have a "reverse current order" command, they would get this functionality for free since they wouldn't want to go to the effort of doing another SORT command when they have all the data at hand. The REVERSE criterion was intended for use with a criteria list of two or more criteria, e.g. SUBJECT REVERSE DATE. > I think all that is really needed is a single paragraph added to the > current SORT draft to explain this Done, as a Note to the REVERSE criterion. We'll have to issue a new SORT draft soon, although I would like it to reflect the new directions being taken with VIEW that were tenatively decided in San Diego. > I would still like to see a UID key in SORT2 I think that this is a no-brainer; if we go to the trouble of adding SORT2 then we should definitely have either UID or SEQUENCE. I see that we're going to have to answer this question over and over again otherwise. > An laternative would be to allow REVERSE to > appear by itself at the end of the key list, and to apply to the implicit > key, given that it only makes sense to have a UID key as the last key. I don't like this at all; it's too magic. Anyway, what's to say that "REVERSE SUBJECT" necessarily means "REVERSE SUBJECT REVERSE UID" instead of "REVERSE SUBJECT UID"? If this means that SORT2 must happen, so be it. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20056 for ietf-imapext-bks; Tue, 19 Dec 2000 09:40:45 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20048 for ; Tue, 19 Dec 2000 09:40:13 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA25389; Tue, 19 Dec 2000 12:41:47 -0500 (EST) Date: Tue, 19 Dec 2000 12:43:01 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <5568138.977229781@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, December 18, 2000 5:32 PM -0800 Mark Crispin wrote: >> SORT FROM gives 2 4 1 3 >> SORT REVERSE FROM gives 1 3 2 4 > > SORT FROM REVERSE UID gives 4 2 3 1, > same as SORT REVERSE FROM, client reverse results > > SORT REVERSE FROM REVERSE UID gives 3 1 4 2, > same as SORT FROM, client reverse results > > > You've given a pretty good demonstration as to why UID should be in any > SORT2, since if this confuses you it'll certainly confuse a newbie. Its not so much that I'm confused, but rather suprised by the fact the client ends up having to do some of the sort work for the reversal case. Yes this is trivial, but I ended up having to special-case it because my local sort implementation took care of the reversal by itself. I think all that is really needed is a single paragraph added to the current SORT draft to explain this, something like: 'If a client wants to get sort results in reverse order, it is generally not sufficient to REVERSE all the keys in the SORT command, as it is not possible to have the server reverse the implicit sequence number sorting. Instead, clients should reverse the sort results themselves to achieve a 'full reversal' of the sort for all keys, without using REVERSE.' I would still like to see a UID key in SORT2 because I think it will make it easier to handle reversals when used in conjunction with VIEW - though one could still argue that it would be trivial for the client to do its own reversal even in that case. An laternative would be to allow REVERSE to appear by itself at the end of the key list, and to apply to the implicit key, given that it only makes sense to have a UID key as the last key. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05228 for ietf-imapext-bks; Mon, 18 Dec 2000 17:34:26 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05224 for ; Mon, 18 Dec 2000 17:34:24 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id RAA03432; Mon, 18 Dec 2000 17:37:19 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (warner@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 RAA22735; Mon, 18 Dec 2000 17:37:19 -0800 Date: Mon, 18 Dec 2000 17:32:28 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison In-Reply-To: <4566581.977167444@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 Mon, 18 Dec 2000 19:24:04 -0500, Cyrus Daboo wrote: > SORT FROM gives 2 4 1 3 > SORT REVERSE FROM gives 1 3 2 4 SORT FROM REVERSE UID gives 4 2 3 1, same as SORT REVERSE FROM, client reverse results SORT REVERSE FROM REVERSE UID gives 3 1 4 2, same as SORT FROM, client reverse results You've given a pretty good demonstration as to why UID should be in any SORT2, since if this confuses you it'll certainly confuse a newbie. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03855 for ietf-imapext-bks; Mon, 18 Dec 2000 16:21:01 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03850 for ; Mon, 18 Dec 2000 16:20:59 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA23455; Mon, 18 Dec 2000 19:22:49 -0500 (EST) Date: Mon, 18 Dec 2000 19:24:04 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <4566581.977167444@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, December 18, 2000 3:46 PM -0800 Mark Crispin wrote: >> For example, there is no way now to >> effectively do for example: 'FROM REVERSE UID'. > > Unless I'm losing more brain cells along with my eyesight, you can do that > with "REVERSE FROM" and reversing the results in the client. No! Consider this simple case of a mailbox with four messages in it: Seq. From 1 Mark 2 Cyrus 3 Mark 4 Cyrus SORT FROM gives 2 4 1 3 SORT REVERSE FROM gives 1 3 2 4 Thus reversing the first set of results (3 1 4 2) is NOT the same as the second set. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03566 for ietf-imapext-bks; Mon, 18 Dec 2000 16:09:21 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (stein@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03562 for ; Mon, 18 Dec 2000 16:09:20 -0800 (PST) Date: Mon, 18 Dec 2000 15:46:42 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: Mark Crispin , IMAP Extensions WG , Ken Murchison In-Reply-To: <2849770.977138897@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 Mon, 18 Dec 2000 11:28:17 -0500, Cyrus Daboo wrote: > Mulberry only provides one-level of sort criteria as well, so doing an > internal reverse of the server results is easy, and that's what I've now > done. Which makes the implementation of a "reverse current sort" client command trivial! > For example, there is no way now to > effectively do for example: 'FROM REVERSE UID'. Unless I'm losing more brain cells along with my eyesight, you can do that with "REVERSE FROM" and reversing the results in the client. For a one-shot deal, "reversing the results in the client" is simply loading the mapping table in reverse. For multiple-times (e.g. when you have an "R" command to reverse the display) you just change the indexing operation from sort_table[i] to sort_table[nmsgs - i] instead of actually moving data around. So, the only purpose to adding UID would be to make it easier to understand; there is no actual functional gain. However, *if* there is a SORT2, then I agree that UID should be one of the added criteria, just so we don't have to explain this over and over again to newbies. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13806 for ietf-imapext-bks; Mon, 18 Dec 2000 09:07:03 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13799 for ; Mon, 18 Dec 2000 09:07:02 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA21857 for ; Mon, 18 Dec 2000 12:08:52 -0500 (EST) Date: Mon, 18 Dec 2000 12:10:07 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: SORT wish list Message-ID: <3000526.977141407@socrates.cyrusoft.com> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are a set of additional SORT criteria that I would like to see added to the existing SORT draft (as SORT2). The following four are all trivial to implement given the current SORT: SENDER - being able to sort on the Sender address can be useful since some automated agents (e.g. mailing lists) typically use this field. Given that sender is one of the ENVELOPE fields and will be cached by the server, it shouldn't be any harder than FROM, TO & CC which are already used. REPLYTO - same argument for ease of implementation as SENDER, though I can't think of any justification for this one right now. FLAGS - being able to, say, sort all unseen messages to the top, or all deleted messages to the bottom is certainly useful. There are two approaches with this: one in which each flag has its own criterion and one where we define an ordering for a general FLAGS criterion (e.g. order is Flagged-Recent/Unseen-Seen-Answered-Deleted). UID - having this would allow reversal of the implicit sequence number sort criterion. Some more fanciful suggestions are: PARTS - sort by the number of parts in a message. This requires the server to count the body parts, but its likely to have the body structure cached. CORRESPONDENT - many clients display the address field in their mailbox (message list) window using either the From or the To address based on whether the message was sent to or sent by the current user (based on their email address and any 'aliases'). Having a sort criteria that dynamically picks either FROM or TO based on the message would enable clients to present the same server-sorted view as they get with local sorting. This means having parameters to the sort criterion that would allow the client to specify the email address(es) of the current user. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11180 for ietf-imapext-bks; Mon, 18 Dec 2000 08:25:59 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11168 for ; Mon, 18 Dec 2000 08:25:57 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21689; Mon, 18 Dec 2000 11:27:45 -0500 (EST) Date: Mon, 18 Dec 2000 11:29:01 -0500 From: Cyrus Daboo To: Ken Murchison cc: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? Message-ID: <2852440.977138941@socrates.cyrusoft.com> In-Reply-To: <3A3C32E6.2B98F710@oceana.com> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Saturday, December 16, 2000 10:28 PM -0500 Ken Murchison wrote: >> What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does >> the implicit sequence number sort also get reversed? > > The more I think about this, the more I kinda like the idea of having > the order (forward/reverse) of the last criterion be "sticky" and also > apply to the implicit criterion (seq number). Since the implicit > criterion is only there to break any ties with the last client-specified > criterion, you could argue that it is an extension of the last criterion > and should inherit its properties. I'd prefer a SORT2 with a UID criterion, especially given your next comment: > That being said, it might be too late to make a change like this with > SORT due to the installed base, expected behavior, yada, yada, yada. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11137 for ietf-imapext-bks; Mon, 18 Dec 2000 08:25:20 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11130 for ; Mon, 18 Dec 2000 08:25:19 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21684; Mon, 18 Dec 2000 11:27:01 -0500 (EST) Date: Mon, 18 Dec 2000 11:28:17 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <2849770.977138897@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Saturday, December 16, 2000 2:11 PM -0800 Mark Crispin wrote: >> Personally I would argue that the server behaviour >> is wrong - reverse sorting ought to apply to the implicit sequence sort >> if REVERSE appears as the first item in the sort keys. > > IMHO, that would be far more magic and confusing! You're probably right! Ken's suggestion of a UID sort criterion would be a better solution if we decide that reversing the implicit sort criterion is needed. >> This also brings up the issue that the current draft does not provide a >> way to do a reverse sort of just sequence number order. >> in conjunction with VIEW (if we ever have that) that >> is arguably a flaw, since clients are likely to want to do, for example, >> VIEW FETCH 1:10 to get messages in reverse sequence number ordering. > > As mentioned earlier, you can do that now by using the identifiers in > reverse. > > You really do have all the states you need. The only time that you need > REVERSE in server-based SORT is if you want to do a criterion inverse to > other criteria. In fact, Pine never uses REVERSE, since it only uses one > criterion in its sorting (after all, if you flip between forward and > reverse order, why ask the server to do that when you have the mapping > table and can do it yourself?). Mulberry only provides one-level of sort criteria as well, so doing an internal reverse of the server results is easy, and that's what I've now done. However, I can envisage situations where multiple serach criteria are required (and somehow available via the GUI), in which case a reverse on the implicit criterion may be needed. For example, there is no way now to effectively do for example: 'FROM REVERSE UID'. Maybe this is a non-sensical case that we can eliminate, but I'm not convinced of that myself. I'll be sending a SORT2 wish-list in another message that should address this a bit more... -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20566 for ietf-imapext-bks; Sat, 16 Dec 2000 19:26:46 -0800 (PST) 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 TAA20562 for ; Sat, 16 Dec 2000 19:26:44 -0800 (PST) Received: from ppp4.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id eBH3SeU22269; Sat, 16 Dec 2000 22:28:40 -0500 Message-ID: <3A3C32E6.2B98F710@oceana.com> Date: Sat, 16 Dec 2000 22:28:38 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? References: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> 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: Cyrus Daboo wrote: > > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? The more I think about this, the more I kinda like the idea of having the order (forward/reverse) of the last criterion be "sticky" and also apply to the implicit criterion (seq number). Since the implicit criterion is only there to break any ties with the last client-specified criterion, you could argue that it is an extension of the last criterion and should inherit its properties. That being said, it might be too late to make a change like this with SORT due to the installed base, expected behavior, yada, yada, yada. 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 OAA14726 for ietf-imapext-bks; Sat, 16 Dec 2000 14:42:24 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (jtis@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14722 for ; Sat, 16 Dec 2000 14:42:21 -0800 (PST) Date: Sat, 16 Dec 2000 14:11:55 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison , Walter Wong , Lawrence Greenfield In-Reply-To: <538169.976977346@gruel-115-186.ppp.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 Sat, 16 Dec 2000 14:35:46 -0500, Cyrus Daboo wrote: > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? No. REVERSE only applies to a single criterion, not to the remaining criteria. > If this is the correct behaviour, then it needs to be clarified in the > draft. The draft already says: REVERSE Followed by another sort criterion, has the effect of that criterion but in reverse order. This seems explicit to me that REVERSE only applies to a single criterion, since otherwise it would have said something like "followed by critera". > Personally I would argue that the server behaviour > is wrong - reverse sorting ought to apply to the implicit sequence sort if > REVERSE appears as the first item in the sort keys. IMHO, that would be far more magic and confusing! In your example of REVERSE SUBJECT where you wanted inverse sequence number collation for identical subjects, you could do this now by doing a SUBJECT and applying the REVERSE semantics in the client. Very likely, it wouldn't even make a difference in the amount of work that a client can do. > This also brings up the issue that the current draft does not provide a way > to do a reverse sort of just sequence number order. > in conjunction with VIEW (if we ever have that) that > is arguably a flaw, since clients are likely to want to do, for example, > VIEW FETCH 1:10 to get messages in reverse sequence number ordering. As mentioned earlier, you can do that now by using the identifiers in reverse. You really do have all the states you need. The only time that you need REVERSE in server-based SORT is if you want to do a criterion inverse to other criteria. In fact, Pine never uses REVERSE, since it only uses one criterion in its sorting (after all, if you flip between forward and reverse order, why ask the server to do that when you have the mapping table and can do it yourself?). Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13819 for ietf-imapext-bks; Sat, 16 Dec 2000 14:05:32 -0800 (PST) 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 OAA13814 for ; Sat, 16 Dec 2000 14:05:30 -0800 (PST) Received: from ppp4.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id eBGM7NU12792; Sat, 16 Dec 2000 17:07:23 -0500 Message-ID: <3A3BE798.8D21A2E2@oceana.com> Date: Sat, 16 Dec 2000 17:07:20 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? References: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> 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: Cyrus Daboo wrote: > > After Thursday's IMAP-ext meeting I went away and implemented support for > SORT in Mulberry. I'm currently testing this out with CMU server (v2.0.7) > and UW server (v12.264 - an old version which I'll update soon). I have a > question about reverse sorting (here's a quote from the draft): > > > If two or more messages exactly match according to the sorting > > criteria, these messages are sorted according to the order in > > which they appear in the mailbox. In other words, there is an > > implicit sort criterion of "sequence number". > > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? I would say no because REVERSE *only* applies to the sort-key immediately following. And since the sequence number is implicit, there is no way to REVERSE it. > In the servers I > tested this is not the case. Reverse sorting the following two messages > does not change their order: > > seq subject > > 92 "Reply" does not put in sender's address > 93 Re: "Reply" does not put in sender's address > > I get the following resonses: > > a SORT (SUBJECT) US-ASCII ALL > * SORT ... 92 93 ... > > a SORT (REVERSE SUBJECT) US-ASCII ALL > * SORT ... 92 93 ... > > If this is the correct behaviour, then it needs to be clarified in the > draft. Yeah, maybe it needs to be clarified since you read it differently than Mark and I. Any suggested text? > Right now my local (Mulberry) sorting (which now uses the subject > extraction rules from the draft) does this the other way, i.e. I get 93 92 > displayed in that order. Personally I would argue that the server behaviour > is wrong - reverse sorting ought to apply to the implicit sequence sort if > REVERSE appears as the first item in the sort keys. You could make an argument that if the last sort key is REVERSEd, then the implicit sort should be reversed as well. But I can also see arguments to the contrary. What would you do with this: x SORT (REVERSE SUBJECT FROM) US-ASCII ALL Would you still reverse the sequence? I would say no. > > This also brings up the issue that the current draft does not provide a way > to do a reverse sort of just sequence number order. This is probably a > silly state as a client can always reverse its own internal notion of > sequence numbers, but in conjunction with VIEW (if we ever have that) that > is arguably a flaw, since clients are likely to want to do, for example, > VIEW FETCH 1:10 to get messages in reverse sequence number ordering. Right > now I know that many of our users do reverse sequence number sorting (they > want to see the latest messages at the top). One could argue that either > DATE or ARRIVAL sorting will give close to the same behaviour, but it won't > be exactly the same. Comments? > I think these issues are why someone suggested a UID sort key. Then you could solve both of your problems with: x SORT (REVERSE SUBJECT REVERSE UID) x SORT (REVERSE UID) Perhaps this is a good time to think about SORT2 stuff? 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 LAA06404 for ietf-imapext-bks; Sat, 16 Dec 2000 11:33:00 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06395 for ; Sat, 16 Dec 2000 11:32:55 -0800 (PST) Received: from gruel-115-186.ppp.andrew.cmu.edu (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA18747; Sat, 16 Dec 2000 14:34:33 -0500 (EST) Date: Sat, 16 Dec 2000 14:35:46 -0500 From: Cyrus Daboo To: IMAP Extensions WG , Ken Murchison , Mark Crispin cc: Walter Wong , Lawrence Greenfield Subject: Reverse sort bug? Message-ID: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After Thursday's IMAP-ext meeting I went away and implemented support for SORT in Mulberry. I'm currently testing this out with CMU server (v2.0.7) and UW server (v12.264 - an old version which I'll update soon). I have a question about reverse sorting (here's a quote from the draft): > If two or more messages exactly match according to the sorting > criteria, these messages are sorted according to the order in > which they appear in the mailbox. In other words, there is an > implicit sort criterion of "sequence number". What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does the implicit sequence number sort also get reversed? In the servers I tested this is not the case. Reverse sorting the following two messages does not change their order: seq subject 92 "Reply" does not put in sender's address 93 Re: "Reply" does not put in sender's address I get the following resonses: a SORT (SUBJECT) US-ASCII ALL * SORT ... 92 93 ... a SORT (REVERSE SUBJECT) US-ASCII ALL * SORT ... 92 93 ... If this is the correct behaviour, then it needs to be clarified in the draft. Right now my local (Mulberry) sorting (which now uses the subject extraction rules from the draft) does this the other way, i.e. I get 93 92 displayed in that order. Personally I would argue that the server behaviour is wrong - reverse sorting ought to apply to the implicit sequence sort if REVERSE appears as the first item in the sort keys. This also brings up the issue that the current draft does not provide a way to do a reverse sort of just sequence number order. This is probably a silly state as a client can always reverse its own internal notion of sequence numbers, but in conjunction with VIEW (if we ever have that) that is arguably a flaw, since clients are likely to want to do, for example, VIEW FETCH 1:10 to get messages in reverse sequence number ordering. Right now I know that many of our users do reverse sequence number sorting (they want to see the latest messages at the top). One could argue that either DATE or ARRIVAL sorting will give close to the same behaviour, but it won't be exactly the same. Comments? -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00375 for ietf-imapext-bks; Fri, 15 Dec 2000 08:49:49 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00369 for ; Fri, 15 Dec 2000 08:49:48 -0800 (PST) Received: from messagingdirect.com (ietf.207.137.72.92.tx.verio.net [207.137.72.92]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eBFGqdv32277; Fri, 15 Dec 2000 09:52:39 -0700 Message-ID: <3A39D3EE.38DB5B62@messagingdirect.com> Date: Fri, 15 Dec 2000 00:18:54 -0800 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG CC: Randall Gellens Subject: Modifying ANNOTATE modtime attribute in APPEND/STORE Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Can a client specify modtime attribute in APPEND? What about STORE? Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06147 for ietf-imapext-bks; Thu, 14 Dec 2000 10:24:57 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06142 for ; Thu, 14 Dec 2000 10:24:54 -0800 (PST) Received: from [207.137.72.203] (207.137.71.221) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2) for ; Thu, 14 Dec 2000 10:19:35 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Thu, 14 Dec 2000 08:19:54 -0800 To: ietf-imapext@imc.org From: Pete Resnick Subject: Fwd: Agenda for IMAPEXT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Not that there are any suprises here, but I guess this should go to the list as well. --- begin forwarded text Date: Tue, 12 Dec 2000 13:29:24 -0800 To: agenda@ietf.org From: Pete Resnick Subject: Agenda for IMAPEXT Agenda for IMAPEXT meeting: 1. Find someone to take minutes/Agenda bashing 2. Discuss drafts ACL - what's going on? LIST extension VIEW/SORT/THREAD Annotate/Regexp/Modtime Binary draft 3. Accomplish world peace --- end forwarded text -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA06720 for ietf-imapext-bks; Wed, 13 Dec 2000 09:38:58 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06716 for ; Wed, 13 Dec 2000 09:38:56 -0800 (PST) Received: from messagingdirect.com (ietf.207.137.74.196.tx.verio.net [207.137.74.196]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eBDHfbv09847; Wed, 13 Dec 2000 10:41:37 -0700 Message-ID: <3A37B4D0.B4F0DCE5@messagingdirect.com> Date: Wed, 13 Dec 2000 09:41:36 -0800 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Strawman: CONDSTORE (conditional STORE extension for flags/annotations) Content-Type: multipart/mixed; boundary="------------618C9223199BC40ADC23A60F" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------618C9223199BC40ADC23A60F Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit I've missed the draft submission deadline, but I've decided it is probably worth discussing anyway. Currently the proposal is not fully compatible with ANNOTATION (and maybe it shouldn't be). Anyway, folks can be interested to read it before IMAPEXT WG meeting. As usual, comments are welcome. Alexey --------------618C9223199BC40ADC23A60F Content-Type: text/plain; charset=koi8-r; name="ietf-melnikov-imap-condstore-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf-melnikov-imap-condstore-00.txt" Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Document: draft-melnikov-imap-condstore-00.txt S. Hole Expires: June 2001 MessagingDirect Ltd. December 2000 IMAP Extension for Conditional STORE operation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. 0.1. Open issues 1). How specify different UNCHANGESINCE for different flags in the same STORE? Do we want such granularity anyway? 2). Should search-modtime specify that SEARCH should perform equality comparison or "equal or greater"? 3). The document assumes that each flag has a corresponding ANNOTATE attribute. How to specify both entry name and attribute in attr-name for annotations? This has to be synchronized with ANNOTATE draft. 4). What MODTIME has a user-defined flag that was never set? What about system flags? 5). Untagged Modtime response used with FETCH/STORE? 6). Add support for SORT extension? MODTIME Message Data Item in STATUS? Table of Contents <> 1. Abstract <> 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The term metadata or metadata item will be used throughout this document. It references any system or user defined flag or an annotation [ANNOTATION]. 3. Introduction and Overview The Conditional STORE extension is present in any IMAP4 implementation which returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response. Every read-write metadata of an IMAP message has an associated value called modification timestamp (modtime). This is an opaque value updated by the server whenever metadata item is modified. The value is intended to be used only for comparisons within a server, not as an accurate timestamp. However the server MUST guarantie that each STORE command (including simultaneous stores from different connections) will use different modtime values. Modtime is described more fully in section 3.1.1 of [ACAP]. Modtime allows the client that supports CONDSTORE extension to track whether the value of particular flag was changed since some moment in time. Whenever the state of a flag change (i.e. the flag is added and before it wasn't set or the flags is removed and before it was set) the value of modification timestamp for that flag MUST be updated. Adding the flag when it is already present of removing when it is not SHOULD NOT change modtime. Each flag SHOULD have separate modtime, for example change to \Draft flag SHOULD NOT affect modtime for \Deleted flag. When message is appended to mailbox (via APPEND command or using external mechanism) the server assigns the current server timestamp to every flag or annotation specified in the APPEND command. When an annotation is removed modtime SHOULD be preserved. This extension makes the following changes to the IMAP4 protocol: a) extends syntax of the STORE command for allowing to specify STORE modifiers b) adds MODIFIED response code that should be used with NO response to STORE c) adds a new MODTIME message data item for use in the FETCH command d) adds a new MODTIME message data item for use in the SEARCH command The rest of this document describes protocol changes more rigorously. 4. IMAP Protocol Changes 4.1. STORE and UID STORE Commands Arguments: message set OPTIONAL store modifiers message data item name value for message data item Responses: untagged responses: FETCH Result: OK - store completed NO - store error: can't store that data BAD - command unknown or arguments invalid This document extends syntax of the STORE (and UID STORE respectively) command (see section 6.4.6 of [IMAP]) to include optional STORE modifiers. The document defines the following modifier: UNCHANGEDSINCE If the "modtime" of any metadata item specified in STORE operation for any message in the message set is greater than the unchangedsince value, then the store fails with a MODIFIED response code that includes message set of all messages that failed UNCHANGESINCE test. Example: C: a101 STORE 7,5,9 (UNCHANGEDSINCE "20000320162338") +FLAGS.SILENT (\Deleted) S: a101 NO [MODIFIED 7,9] Conditional STORE failed Use of UNCHANGEDSINCE with a time of "00000101000000" will always fail if the metadata item exists. Example: C: a102 STORE 12 (UNCHANGEDSINCE "00000101000000") +FLAGS.SILENT ($MDNSent) S: a102 NO [MODIFIED 12] Conditional STORE failed If operation is successful the server MUST update the "modtime" attribute for every metadata item that was changed. Untagged FETCH response MUST be sent even if .SILENT is specified and it MUST include MODTIME message data item as described in 4.2. Example: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODTIME ("/message/flags/system/\\Deleted" "200012111230045")) S: * 2 FETCH (UID 6 MODTIME ("/message/flags/system/\\Deleted" "200012101230045")) S: * 4 FETCH (UID 8 MODTIME ("/message/flags/system/\\Deleted" "200012121130045")) S: a103 OK Store completed Example: C: a104 STORE * (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted $Processed) S: * 50 FETCH (MODTIME ("/message/flags/system/\\Deleted" "200012111230045" "/message/flags/system/$Processed" "200012111230045")) S: a104 OK Store completed In the latter example UNCHANGEDSINCE value is checked against modtimes for both flags. Note: If the message is specified multiple times in the message set and the server doesn't internally eliminate duplicates from the message set it MUST NOT fail conditional STORE operation for the second occurence of the message in the message set if operation completed succesfully for the first occurence. For example, if the client specifies: a100 STORE 7,3:9 (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted) the server must not fail operation for the message 7 as a part of processing "3:9" if it succeeded when the message 7 was processed the first time. 4.2. MODTIME message data item in FETCH Command This extension adds an MODTIME message data item to the FETCH command. This allows clients to retrieve modtime for various metadata items for a range of messages in the currently selected mailbox. MODTIME The MODTIME message data item, when used by the client in the FETCH command, takes a list of metadata items. For a flag the corresponding attr-name has a form "/message/flags/system/" Example: C: a FETCH 1 (MODTIME ("/message/comment" "/message/flags/system/$MDNSent")) S: * 1 FETCH (MODTIME ("/message/comment" 112 "/message/flags/system/$MDNSent" 64)) S: a OK Fetch complete 4.3 MODTIME criterion in SEARCH The MODTIME criterion for the SEARCH command allows a client to search for the specified modtime of a metadata item in a message. MODTIME Messages that have modification counter for metadata item with value equal or greater than . This allows a client, for example, to find out which messages contain metadata items that have changed since the last time it updated its disconnected cache. Examples: C: a SEARCH MODTIME "/message/flags/system/\\draft" "20010320162338" ANNOTATION "/message/comment" "value" "IMAP4" S: * SEARCH 2 3 5 7 11 13 17 19 23 S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the "/message/comment" entry and having modtime "20010320162338" for flag \Draft are returned in the search results. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [IMAP4]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. store = "STORE" SP set SP store-modifiers store-att-flags store-modifiers = [ "(" 1*store-modifier ")" ] store-modifier = "UNCHANGEDSINCE" time fetch-att =/ fetch-modtime ; modifies original IMAP4 fetch-att fetch-modtime = "MODTIME" SP "(" 1*attr-name ")" fetch-mod-resp = "MODTIME" SP "(" 1*(attr-name SP counter) ")" search-key =/ search-modtime ; modifies original IMAP4 search-key search-modtime = "MODTIME" SP attr-name SP counter resp-text-code =/ "MODIFIED" SP set attr-name = "/message/flags/system/" attr-flag ;; each system or user defined flag is mapped to ;; "/message/flags/system/" <> attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / "\\Seen" / "\\Draft" / attr-flag-keyword / attr-flag-extension ; Does not include "\Recent" attr-flag-extension = "\\" atom ; Future expansion. Client implementations ; MUST accept flag-extension flags. Server ; implementations MUST NOT generate ; flag-extension flags except as defined by ; future standard or standards-track ; revisions of this specification. attr-flag-keyword = atom <> time = <"> time-year time-month time-day time-hour time-minute time-second time-subsecond <"> ;; Timestamp in UTC time-day = 2DIGIT ;; 01-31 time-hour = 2DIGIT ;; 00-23 time-minute = 2DIGIT ;; 00-59 time-month = 2DIGIT ;; 01-12 time-second = 2DIGIT ;; 00-60 time-subsecond = *DIGIT time-year = 4DIGIT 6. Security Considerations There are no known security issues with this extension. 7. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", work in progress. [SORT-EXT] Crispin, M., "Internet Message Access Protocol -- SORT Extension", work in progress. 8. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. --------------618C9223199BC40ADC23A60F-- Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28070 for ietf-imapext-bks; Fri, 22 Dec 2000 22:56:50 -0800 (PST) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28063 for ; Fri, 22 Dec 2000 22:56:48 -0800 (PST) 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+UW00.01) with ESMTP id XAA18902; Fri, 22 Dec 2000 23:00:09 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (dlg@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 XAA26378; Fri, 22 Dec 2000 23:00:09 -0800 Date: Fri, 22 Dec 2000 22:38:02 -0800 (PST) From: Mark Crispin Subject: re: SORT wish list To: Cyrus Daboo cc: IMAP Extensions WG In-Reply-To: <3000526.977141407@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: Cyrus - The only one of your proposed new criteria that I really worry about is PARTS, since that requires obtaining the body structure. Unless it is cached, this represents a much more expensive operation than the others, which are either in fast meta-data (INTERNALDATE, FLAGS, RFC822.SIZE) or the RFC822 header (and likely the envelope). The implementation is straightforward enough, but getting it to finish before the sun novas is a different matter. Here's my comments, such as they are, about the other suggestions: FLAGS has an arguable use. I don't think that, by itself, it justifies creating SORT2; but it should certainly be part of SORT2 if it happens. Adding something like UID, as noted earlier, is a no-brainer. However, there is one problem with that UID acts as a terminal criterion; no criterion may follow it or they'll be ignored. A way around this would be to allow REVERSE as the final criterion to affect the implicit reverse sequence, e.g. REVERSE SUBJECT REVERSE. SENDER and REPLYTO aren't reasonably implementable with NNTP overviews (which is a concern in my implementation since one of the mail stores I can export is an NNTP-accessed newsgroup). Then again, neither are TO and CC; and I just issue an error message saying "you can't do that" for those. So there's a precedent... CORRESPONDENT has the same problem with overviews as SENDER/REPLYTO, plus it requires some mechanism for the server to learn about "aliases" to the user's email address. Actually, since the server only knows the login identifier and that doesn't have any necessary correspondence to the email address, there needs to be a means to identify the user's email address! This idea is a good one, but as it currently stands it is half-baked. IMHO, it may be the feature that is make/break for SORT2, so I recommend that you give some thought to it. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27391 for ietf-imapext-bks; Fri, 22 Dec 2000 22:34:36 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27375 for ; Fri, 22 Dec 2000 22:34:32 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id WAA13556; Fri, 22 Dec 2000 22:37:53 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (ccx@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 WAA25983; Fri, 22 Dec 2000 22:37:53 -0800 Date: Fri, 22 Dec 2000 22:23:45 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison In-Reply-To: <5568138.977229781@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 Tue, 19 Dec 2000 12:43:01 -0500, Cyrus Daboo wrote: > Its not so much that I'm confused, but rather suprised by the fact the > client ends up having to do some of the sort work for the reversal case. Well, given that many clients have a "reverse current order" command, they would get this functionality for free since they wouldn't want to go to the effort of doing another SORT command when they have all the data at hand. The REVERSE criterion was intended for use with a criteria list of two or more criteria, e.g. SUBJECT REVERSE DATE. > I think all that is really needed is a single paragraph added to the > current SORT draft to explain this Done, as a Note to the REVERSE criterion. We'll have to issue a new SORT draft soon, although I would like it to reflect the new directions being taken with VIEW that were tenatively decided in San Diego. > I would still like to see a UID key in SORT2 I think that this is a no-brainer; if we go to the trouble of adding SORT2 then we should definitely have either UID or SEQUENCE. I see that we're going to have to answer this question over and over again otherwise. > An laternative would be to allow REVERSE to > appear by itself at the end of the key list, and to apply to the implicit > key, given that it only makes sense to have a UID key as the last key. I don't like this at all; it's too magic. Anyway, what's to say that "REVERSE SUBJECT" necessarily means "REVERSE SUBJECT REVERSE UID" instead of "REVERSE SUBJECT UID"? If this means that SORT2 must happen, so be it. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA20056 for ietf-imapext-bks; Tue, 19 Dec 2000 09:40:45 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20048 for ; Tue, 19 Dec 2000 09:40:13 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA25389; Tue, 19 Dec 2000 12:41:47 -0500 (EST) Date: Tue, 19 Dec 2000 12:43:01 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <5568138.977229781@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, December 18, 2000 5:32 PM -0800 Mark Crispin wrote: >> SORT FROM gives 2 4 1 3 >> SORT REVERSE FROM gives 1 3 2 4 > > SORT FROM REVERSE UID gives 4 2 3 1, > same as SORT REVERSE FROM, client reverse results > > SORT REVERSE FROM REVERSE UID gives 3 1 4 2, > same as SORT FROM, client reverse results > > > You've given a pretty good demonstration as to why UID should be in any > SORT2, since if this confuses you it'll certainly confuse a newbie. Its not so much that I'm confused, but rather suprised by the fact the client ends up having to do some of the sort work for the reversal case. Yes this is trivial, but I ended up having to special-case it because my local sort implementation took care of the reversal by itself. I think all that is really needed is a single paragraph added to the current SORT draft to explain this, something like: 'If a client wants to get sort results in reverse order, it is generally not sufficient to REVERSE all the keys in the SORT command, as it is not possible to have the server reverse the implicit sequence number sorting. Instead, clients should reverse the sort results themselves to achieve a 'full reversal' of the sort for all keys, without using REVERSE.' I would still like to see a UID key in SORT2 because I think it will make it easier to handle reversals when used in conjunction with VIEW - though one could still argue that it would be trivial for the client to do its own reversal even in that case. An laternative would be to allow REVERSE to appear by itself at the end of the key list, and to apply to the implicit key, given that it only makes sense to have a UID key as the last key. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05228 for ietf-imapext-bks; Mon, 18 Dec 2000 17:34:26 -0800 (PST) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05224 for ; Mon, 18 Dec 2000 17:34:24 -0800 (PST) Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2]) by mxout2.cac.washington.edu (8.9.3+UW00.02/8.9.3+UW00.01) with ESMTP id RAA03432; Mon, 18 Dec 2000 17:37:19 -0800 Received: from Tomobiki-Cho.CAC.Washington.EDU (warner@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 RAA22735; Mon, 18 Dec 2000 17:37:19 -0800 Date: Mon, 18 Dec 2000 17:32:28 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison In-Reply-To: <4566581.977167444@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 Mon, 18 Dec 2000 19:24:04 -0500, Cyrus Daboo wrote: > SORT FROM gives 2 4 1 3 > SORT REVERSE FROM gives 1 3 2 4 SORT FROM REVERSE UID gives 4 2 3 1, same as SORT REVERSE FROM, client reverse results SORT REVERSE FROM REVERSE UID gives 3 1 4 2, same as SORT FROM, client reverse results You've given a pretty good demonstration as to why UID should be in any SORT2, since if this confuses you it'll certainly confuse a newbie. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03855 for ietf-imapext-bks; Mon, 18 Dec 2000 16:21:01 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03850 for ; Mon, 18 Dec 2000 16:20:59 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA23455; Mon, 18 Dec 2000 19:22:49 -0500 (EST) Date: Mon, 18 Dec 2000 19:24:04 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <4566581.977167444@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, December 18, 2000 3:46 PM -0800 Mark Crispin wrote: >> For example, there is no way now to >> effectively do for example: 'FROM REVERSE UID'. > > Unless I'm losing more brain cells along with my eyesight, you can do that > with "REVERSE FROM" and reversing the results in the client. No! Consider this simple case of a mailbox with four messages in it: Seq. From 1 Mark 2 Cyrus 3 Mark 4 Cyrus SORT FROM gives 2 4 1 3 SORT REVERSE FROM gives 1 3 2 4 Thus reversing the first set of results (3 1 4 2) is NOT the same as the second set. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03566 for ietf-imapext-bks; Mon, 18 Dec 2000 16:09:21 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (stein@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03562 for ; Mon, 18 Dec 2000 16:09:20 -0800 (PST) Date: Mon, 18 Dec 2000 15:46:42 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: Mark Crispin , IMAP Extensions WG , Ken Murchison In-Reply-To: <2849770.977138897@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 Mon, 18 Dec 2000 11:28:17 -0500, Cyrus Daboo wrote: > Mulberry only provides one-level of sort criteria as well, so doing an > internal reverse of the server results is easy, and that's what I've now > done. Which makes the implementation of a "reverse current sort" client command trivial! > For example, there is no way now to > effectively do for example: 'FROM REVERSE UID'. Unless I'm losing more brain cells along with my eyesight, you can do that with "REVERSE FROM" and reversing the results in the client. For a one-shot deal, "reversing the results in the client" is simply loading the mapping table in reverse. For multiple-times (e.g. when you have an "R" command to reverse the display) you just change the indexing operation from sort_table[i] to sort_table[nmsgs - i] instead of actually moving data around. So, the only purpose to adding UID would be to make it easier to understand; there is no actual functional gain. However, *if* there is a SORT2, then I agree that UID should be one of the added criteria, just so we don't have to explain this over and over again to newbies. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13806 for ietf-imapext-bks; Mon, 18 Dec 2000 09:07:03 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13799 for ; Mon, 18 Dec 2000 09:07:02 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA21857 for ; Mon, 18 Dec 2000 12:08:52 -0500 (EST) Date: Mon, 18 Dec 2000 12:10:07 -0500 From: Cyrus Daboo To: IMAP Extensions WG Subject: SORT wish list Message-ID: <3000526.977141407@socrates.cyrusoft.com> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are a set of additional SORT criteria that I would like to see added to the existing SORT draft (as SORT2). The following four are all trivial to implement given the current SORT: SENDER - being able to sort on the Sender address can be useful since some automated agents (e.g. mailing lists) typically use this field. Given that sender is one of the ENVELOPE fields and will be cached by the server, it shouldn't be any harder than FROM, TO & CC which are already used. REPLYTO - same argument for ease of implementation as SENDER, though I can't think of any justification for this one right now. FLAGS - being able to, say, sort all unseen messages to the top, or all deleted messages to the bottom is certainly useful. There are two approaches with this: one in which each flag has its own criterion and one where we define an ordering for a general FLAGS criterion (e.g. order is Flagged-Recent/Unseen-Seen-Answered-Deleted). UID - having this would allow reversal of the implicit sequence number sort criterion. Some more fanciful suggestions are: PARTS - sort by the number of parts in a message. This requires the server to count the body parts, but its likely to have the body structure cached. CORRESPONDENT - many clients display the address field in their mailbox (message list) window using either the From or the To address based on whether the message was sent to or sent by the current user (based on their email address and any 'aliases'). Having a sort criteria that dynamically picks either FROM or TO based on the message would enable clients to present the same server-sorted view as they get with local sorting. This means having parameters to the sort criterion that would allow the client to specify the email address(es) of the current user. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11180 for ietf-imapext-bks; Mon, 18 Dec 2000 08:25:59 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11168 for ; Mon, 18 Dec 2000 08:25:57 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21689; Mon, 18 Dec 2000 11:27:45 -0500 (EST) Date: Mon, 18 Dec 2000 11:29:01 -0500 From: Cyrus Daboo To: Ken Murchison cc: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? Message-ID: <2852440.977138941@socrates.cyrusoft.com> In-Reply-To: <3A3C32E6.2B98F710@oceana.com> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Saturday, December 16, 2000 10:28 PM -0500 Ken Murchison wrote: >> What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does >> the implicit sequence number sort also get reversed? > > The more I think about this, the more I kinda like the idea of having > the order (forward/reverse) of the last criterion be "sticky" and also > apply to the implicit criterion (seq number). Since the implicit > criterion is only there to break any ties with the last client-specified > criterion, you could argue that it is an extension of the last criterion > and should inherit its properties. I'd prefer a SORT2 with a UID criterion, especially given your next comment: > That being said, it might be too late to make a change like this with > SORT due to the installed base, expected behavior, yada, yada, yada. -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11137 for ietf-imapext-bks; Mon, 18 Dec 2000 08:25:20 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11130 for ; Mon, 18 Dec 2000 08:25:19 -0800 (PST) Received: from socrates.cyrusoft.com (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id LAA21684; Mon, 18 Dec 2000 11:27:01 -0500 (EST) Date: Mon, 18 Dec 2000 11:28:17 -0500 From: Cyrus Daboo To: Mark Crispin cc: IMAP Extensions WG , Ken Murchison Subject: re: Reverse sort bug? Message-ID: <2849770.977138897@socrates.cyrusoft.com> In-Reply-To: X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Saturday, December 16, 2000 2:11 PM -0800 Mark Crispin wrote: >> Personally I would argue that the server behaviour >> is wrong - reverse sorting ought to apply to the implicit sequence sort >> if REVERSE appears as the first item in the sort keys. > > IMHO, that would be far more magic and confusing! You're probably right! Ken's suggestion of a UID sort criterion would be a better solution if we decide that reversing the implicit sort criterion is needed. >> This also brings up the issue that the current draft does not provide a >> way to do a reverse sort of just sequence number order. >> in conjunction with VIEW (if we ever have that) that >> is arguably a flaw, since clients are likely to want to do, for example, >> VIEW FETCH 1:10 to get messages in reverse sequence number ordering. > > As mentioned earlier, you can do that now by using the identifiers in > reverse. > > You really do have all the states you need. The only time that you need > REVERSE in server-based SORT is if you want to do a criterion inverse to > other criteria. In fact, Pine never uses REVERSE, since it only uses one > criterion in its sorting (after all, if you flip between forward and > reverse order, why ask the server to do that when you have the mapping > table and can do it yourself?). Mulberry only provides one-level of sort criteria as well, so doing an internal reverse of the server results is easy, and that's what I've now done. However, I can envisage situations where multiple serach criteria are required (and somehow available via the GUI), in which case a reverse on the implicit criterion may be needed. For example, there is no way now to effectively do for example: 'FROM REVERSE UID'. Maybe this is a non-sensical case that we can eliminate, but I'm not convinced of that myself. I'll be sending a SORT2 wish-list in another message that should address this a bit more... -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id TAA20566 for ietf-imapext-bks; Sat, 16 Dec 2000 19:26:46 -0800 (PST) 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 TAA20562 for ; Sat, 16 Dec 2000 19:26:44 -0800 (PST) Received: from ppp4.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id eBH3SeU22269; Sat, 16 Dec 2000 22:28:40 -0500 Message-ID: <3A3C32E6.2B98F710@oceana.com> Date: Sat, 16 Dec 2000 22:28:38 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? References: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> 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: Cyrus Daboo wrote: > > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? The more I think about this, the more I kinda like the idea of having the order (forward/reverse) of the last criterion be "sticky" and also apply to the implicit criterion (seq number). Since the implicit criterion is only there to break any ties with the last client-specified criterion, you could argue that it is an extension of the last criterion and should inherit its properties. That being said, it might be too late to make a change like this with SORT due to the installed base, expected behavior, yada, yada, yada. 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 OAA14726 for ietf-imapext-bks; Sat, 16 Dec 2000 14:42:24 -0800 (PST) Received: from Tomobiki-Cho.CAC.Washington.EDU (jtis@tomobiki-cho.cac.washington.edu [128.95.135.58]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14722 for ; Sat, 16 Dec 2000 14:42:21 -0800 (PST) Date: Sat, 16 Dec 2000 14:11:55 -0800 (PST) From: Mark Crispin Subject: re: Reverse sort bug? To: Cyrus Daboo cc: IMAP Extensions WG , Ken Murchison , Walter Wong , Lawrence Greenfield In-Reply-To: <538169.976977346@gruel-115-186.ppp.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 Sat, 16 Dec 2000 14:35:46 -0500, Cyrus Daboo wrote: > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? No. REVERSE only applies to a single criterion, not to the remaining criteria. > If this is the correct behaviour, then it needs to be clarified in the > draft. The draft already says: REVERSE Followed by another sort criterion, has the effect of that criterion but in reverse order. This seems explicit to me that REVERSE only applies to a single criterion, since otherwise it would have said something like "followed by critera". > Personally I would argue that the server behaviour > is wrong - reverse sorting ought to apply to the implicit sequence sort if > REVERSE appears as the first item in the sort keys. IMHO, that would be far more magic and confusing! In your example of REVERSE SUBJECT where you wanted inverse sequence number collation for identical subjects, you could do this now by doing a SUBJECT and applying the REVERSE semantics in the client. Very likely, it wouldn't even make a difference in the amount of work that a client can do. > This also brings up the issue that the current draft does not provide a way > to do a reverse sort of just sequence number order. > in conjunction with VIEW (if we ever have that) that > is arguably a flaw, since clients are likely to want to do, for example, > VIEW FETCH 1:10 to get messages in reverse sequence number ordering. As mentioned earlier, you can do that now by using the identifiers in reverse. You really do have all the states you need. The only time that you need REVERSE in server-based SORT is if you want to do a criterion inverse to other criteria. In fact, Pine never uses REVERSE, since it only uses one criterion in its sorting (after all, if you flip between forward and reverse order, why ask the server to do that when you have the mapping table and can do it yourself?). Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA13819 for ietf-imapext-bks; Sat, 16 Dec 2000 14:05:32 -0800 (PST) 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 OAA13814 for ; Sat, 16 Dec 2000 14:05:30 -0800 (PST) Received: from ppp4.oceana.com by eagle.oceana.com (Switch-2.0.5/Switch-2.0.5) with ESMTP id eBGM7NU12792; Sat, 16 Dec 2000 17:07:23 -0500 Message-ID: <3A3BE798.8D21A2E2@oceana.com> Date: Sat, 16 Dec 2000 17:07:20 -0500 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Cyrus Daboo CC: IMAP Extensions WG , Mark Crispin , Walter Wong , Lawrence Greenfield Subject: Re: Reverse sort bug? References: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> 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: Cyrus Daboo wrote: > > After Thursday's IMAP-ext meeting I went away and implemented support for > SORT in Mulberry. I'm currently testing this out with CMU server (v2.0.7) > and UW server (v12.264 - an old version which I'll update soon). I have a > question about reverse sorting (here's a quote from the draft): > > > If two or more messages exactly match according to the sorting > > criteria, these messages are sorted according to the order in > > which they appear in the mailbox. In other words, there is an > > implicit sort criterion of "sequence number". > > What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does > the implicit sequence number sort also get reversed? I would say no because REVERSE *only* applies to the sort-key immediately following. And since the sequence number is implicit, there is no way to REVERSE it. > In the servers I > tested this is not the case. Reverse sorting the following two messages > does not change their order: > > seq subject > > 92 "Reply" does not put in sender's address > 93 Re: "Reply" does not put in sender's address > > I get the following resonses: > > a SORT (SUBJECT) US-ASCII ALL > * SORT ... 92 93 ... > > a SORT (REVERSE SUBJECT) US-ASCII ALL > * SORT ... 92 93 ... > > If this is the correct behaviour, then it needs to be clarified in the > draft. Yeah, maybe it needs to be clarified since you read it differently than Mark and I. Any suggested text? > Right now my local (Mulberry) sorting (which now uses the subject > extraction rules from the draft) does this the other way, i.e. I get 93 92 > displayed in that order. Personally I would argue that the server behaviour > is wrong - reverse sorting ought to apply to the implicit sequence sort if > REVERSE appears as the first item in the sort keys. You could make an argument that if the last sort key is REVERSEd, then the implicit sort should be reversed as well. But I can also see arguments to the contrary. What would you do with this: x SORT (REVERSE SUBJECT FROM) US-ASCII ALL Would you still reverse the sequence? I would say no. > > This also brings up the issue that the current draft does not provide a way > to do a reverse sort of just sequence number order. This is probably a > silly state as a client can always reverse its own internal notion of > sequence numbers, but in conjunction with VIEW (if we ever have that) that > is arguably a flaw, since clients are likely to want to do, for example, > VIEW FETCH 1:10 to get messages in reverse sequence number ordering. Right > now I know that many of our users do reverse sequence number sorting (they > want to see the latest messages at the top). One could argue that either > DATE or ARRIVAL sorting will give close to the same behaviour, but it won't > be exactly the same. Comments? > I think these issues are why someone suggested a UID sort key. Then you could solve both of your problems with: x SORT (REVERSE SUBJECT REVERSE UID) x SORT (REVERSE UID) Perhaps this is a good time to think about SORT2 stuff? 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 LAA06404 for ietf-imapext-bks; Sat, 16 Dec 2000 11:33:00 -0800 (PST) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06395 for ; Sat, 16 Dec 2000 11:32:55 -0800 (PST) Received: from gruel-115-186.ppp.andrew.cmu.edu (tigris.cyrusoft.com [206.31.218.211]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id OAA18747; Sat, 16 Dec 2000 14:34:33 -0500 (EST) Date: Sat, 16 Dec 2000 14:35:46 -0500 From: Cyrus Daboo To: IMAP Extensions WG , Ken Murchison , Mark Crispin cc: Walter Wong , Lawrence Greenfield Subject: Reverse sort bug? Message-ID: <538169.976977346@gruel-115-186.ppp.andrew.cmu.edu> X-Mailer: Mulberry/2.1.0a1 (Mac OS/PPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After Thursday's IMAP-ext meeting I went away and implemented support for SORT in Mulberry. I'm currently testing this out with CMU server (v2.0.7) and UW server (v12.264 - an old version which I'll update soon). I have a question about reverse sorting (here's a quote from the draft): > If two or more messages exactly match according to the sorting > criteria, these messages are sorted according to the order in > which they appear in the mailbox. In other words, there is an > implicit sort criterion of "sequence number". What happens when REVERSE is applied, as in SORT (REVERSE SUBJECT)? Does the implicit sequence number sort also get reversed? In the servers I tested this is not the case. Reverse sorting the following two messages does not change their order: seq subject 92 "Reply" does not put in sender's address 93 Re: "Reply" does not put in sender's address I get the following resonses: a SORT (SUBJECT) US-ASCII ALL * SORT ... 92 93 ... a SORT (REVERSE SUBJECT) US-ASCII ALL * SORT ... 92 93 ... If this is the correct behaviour, then it needs to be clarified in the draft. Right now my local (Mulberry) sorting (which now uses the subject extraction rules from the draft) does this the other way, i.e. I get 93 92 displayed in that order. Personally I would argue that the server behaviour is wrong - reverse sorting ought to apply to the implicit sequence sort if REVERSE appears as the first item in the sort keys. This also brings up the issue that the current draft does not provide a way to do a reverse sort of just sequence number order. This is probably a silly state as a client can always reverse its own internal notion of sequence numbers, but in conjunction with VIEW (if we ever have that) that is arguably a flaw, since clients are likely to want to do, for example, VIEW FETCH 1:10 to get messages in reverse sequence number ordering. Right now I know that many of our users do reverse sequence number sorting (they want to see the latest messages at the top). One could argue that either DATE or ARRIVAL sorting will give close to the same behaviour, but it won't be exactly the same. Comments? -- Cyrus Daboo Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00375 for ietf-imapext-bks; Fri, 15 Dec 2000 08:49:49 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00369 for ; Fri, 15 Dec 2000 08:49:48 -0800 (PST) Received: from messagingdirect.com (ietf.207.137.72.92.tx.verio.net [207.137.72.92]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eBFGqdv32277; Fri, 15 Dec 2000 09:52:39 -0700 Message-ID: <3A39D3EE.38DB5B62@messagingdirect.com> Date: Fri, 15 Dec 2000 00:18:54 -0800 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG CC: Randall Gellens Subject: Modifying ANNOTATE modtime attribute in APPEND/STORE Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Can a client specify modtime attribute in APPEND? What about STORE? Alexey Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06147 for ietf-imapext-bks; Thu, 14 Dec 2000 10:24:57 -0800 (PST) Received: from episteme-software.com (presnick-fw.flexabit.net [64.198.230.34]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06142 for ; Thu, 14 Dec 2000 10:24:54 -0800 (PST) Received: from [207.137.72.203] (207.137.71.221) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.2) for ; Thu, 14 Dec 2000 10:19:35 -0600 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 5.1a1-12.00] Date: Thu, 14 Dec 2000 08:19:54 -0800 To: ietf-imapext@imc.org From: Pete Resnick Subject: Fwd: Agenda for IMAPEXT Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Not that there are any suprises here, but I guess this should go to the list as well. --- begin forwarded text Date: Tue, 12 Dec 2000 13:29:24 -0800 To: agenda@ietf.org From: Pete Resnick Subject: Agenda for IMAPEXT Agenda for IMAPEXT meeting: 1. Find someone to take minutes/Agenda bashing 2. Discuss drafts ACL - what's going on? LIST extension VIEW/SORT/THREAD Annotate/Regexp/Modtime Binary draft 3. Accomplish world peace --- end forwarded text -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA06720 for ietf-imapext-bks; Wed, 13 Dec 2000 09:38:58 -0800 (PST) Received: from rembrandt.esys.ca (IDENT:root@rembrandt.esys.ca [198.161.92.131]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA06716 for ; Wed, 13 Dec 2000 09:38:56 -0800 (PST) Received: from messagingdirect.com (ietf.207.137.74.196.tx.verio.net [207.137.74.196]) (authenticated) by rembrandt.esys.ca (8.11.0.Beta0/8.11.0.Beta0) with ESMTP id eBDHfbv09847; Wed, 13 Dec 2000 10:41:37 -0700 Message-ID: <3A37B4D0.B4F0DCE5@messagingdirect.com> Date: Wed, 13 Dec 2000 09:41:36 -0800 From: Alexey Melnikov X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IMAP Extensions WG Subject: Strawman: CONDSTORE (conditional STORE extension for flags/annotations) Content-Type: multipart/mixed; boundary="------------618C9223199BC40ADC23A60F" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------618C9223199BC40ADC23A60F Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit I've missed the draft submission deadline, but I've decided it is probably worth discussing anyway. Currently the proposal is not fully compatible with ANNOTATION (and maybe it shouldn't be). Anyway, folks can be interested to read it before IMAPEXT WG meeting. As usual, comments are welcome. Alexey --------------618C9223199BC40ADC23A60F Content-Type: text/plain; charset=koi8-r; name="ietf-melnikov-imap-condstore-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ietf-melnikov-imap-condstore-00.txt" Internet Draft: IMAP Extension for Conditional STORE A. Melnikov Document: draft-melnikov-imap-condstore-00.txt S. Hole Expires: June 2001 MessagingDirect Ltd. December 2000 IMAP Extension for Conditional STORE operation Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. 0.1. Open issues 1). How specify different UNCHANGESINCE for different flags in the same STORE? Do we want such granularity anyway? 2). Should search-modtime specify that SEARCH should perform equality comparison or "equal or greater"? 3). The document assumes that each flag has a corresponding ANNOTATE attribute. How to specify both entry name and attribute in attr-name for annotations? This has to be synchronized with ANNOTATE draft. 4). What MODTIME has a user-defined flag that was never set? What about system flags? 5). Untagged Modtime response used with FETCH/STORE? 6). Add support for SORT extension? MODTIME Message Data Item in STATUS? Table of Contents <> 1. Abstract <> 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The term metadata or metadata item will be used throughout this document. It references any system or user defined flag or an annotation [ANNOTATION]. 3. Introduction and Overview The Conditional STORE extension is present in any IMAP4 implementation which returns "CONDSTORE" as one of the supported capabilities in the CAPABILITY command response. Every read-write metadata of an IMAP message has an associated value called modification timestamp (modtime). This is an opaque value updated by the server whenever metadata item is modified. The value is intended to be used only for comparisons within a server, not as an accurate timestamp. However the server MUST guarantie that each STORE command (including simultaneous stores from different connections) will use different modtime values. Modtime is described more fully in section 3.1.1 of [ACAP]. Modtime allows the client that supports CONDSTORE extension to track whether the value of particular flag was changed since some moment in time. Whenever the state of a flag change (i.e. the flag is added and before it wasn't set or the flags is removed and before it was set) the value of modification timestamp for that flag MUST be updated. Adding the flag when it is already present of removing when it is not SHOULD NOT change modtime. Each flag SHOULD have separate modtime, for example change to \Draft flag SHOULD NOT affect modtime for \Deleted flag. When message is appended to mailbox (via APPEND command or using external mechanism) the server assigns the current server timestamp to every flag or annotation specified in the APPEND command. When an annotation is removed modtime SHOULD be preserved. This extension makes the following changes to the IMAP4 protocol: a) extends syntax of the STORE command for allowing to specify STORE modifiers b) adds MODIFIED response code that should be used with NO response to STORE c) adds a new MODTIME message data item for use in the FETCH command d) adds a new MODTIME message data item for use in the SEARCH command The rest of this document describes protocol changes more rigorously. 4. IMAP Protocol Changes 4.1. STORE and UID STORE Commands Arguments: message set OPTIONAL store modifiers message data item name value for message data item Responses: untagged responses: FETCH Result: OK - store completed NO - store error: can't store that data BAD - command unknown or arguments invalid This document extends syntax of the STORE (and UID STORE respectively) command (see section 6.4.6 of [IMAP]) to include optional STORE modifiers. The document defines the following modifier: UNCHANGEDSINCE If the "modtime" of any metadata item specified in STORE operation for any message in the message set is greater than the unchangedsince value, then the store fails with a MODIFIED response code that includes message set of all messages that failed UNCHANGESINCE test. Example: C: a101 STORE 7,5,9 (UNCHANGEDSINCE "20000320162338") +FLAGS.SILENT (\Deleted) S: a101 NO [MODIFIED 7,9] Conditional STORE failed Use of UNCHANGEDSINCE with a time of "00000101000000" will always fail if the metadata item exists. Example: C: a102 STORE 12 (UNCHANGEDSINCE "00000101000000") +FLAGS.SILENT ($MDNSent) S: a102 NO [MODIFIED 12] Conditional STORE failed If operation is successful the server MUST update the "modtime" attribute for every metadata item that was changed. Untagged FETCH response MUST be sent even if .SILENT is specified and it MUST include MODTIME message data item as described in 4.2. Example: C: a103 UID STORE 6,4,8 (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted) S: * 1 FETCH (UID 4 MODTIME ("/message/flags/system/\\Deleted" "200012111230045")) S: * 2 FETCH (UID 6 MODTIME ("/message/flags/system/\\Deleted" "200012101230045")) S: * 4 FETCH (UID 8 MODTIME ("/message/flags/system/\\Deleted" "200012121130045")) S: a103 OK Store completed Example: C: a104 STORE * (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted $Processed) S: * 50 FETCH (MODTIME ("/message/flags/system/\\Deleted" "200012111230045" "/message/flags/system/$Processed" "200012111230045")) S: a104 OK Store completed In the latter example UNCHANGEDSINCE value is checked against modtimes for both flags. Note: If the message is specified multiple times in the message set and the server doesn't internally eliminate duplicates from the message set it MUST NOT fail conditional STORE operation for the second occurence of the message in the message set if operation completed succesfully for the first occurence. For example, if the client specifies: a100 STORE 7,3:9 (UNCHANGEDSINCE "200012121230045") +FLAGS.SILENT (\Deleted) the server must not fail operation for the message 7 as a part of processing "3:9" if it succeeded when the message 7 was processed the first time. 4.2. MODTIME message data item in FETCH Command This extension adds an MODTIME message data item to the FETCH command. This allows clients to retrieve modtime for various metadata items for a range of messages in the currently selected mailbox. MODTIME The MODTIME message data item, when used by the client in the FETCH command, takes a list of metadata items. For a flag the corresponding attr-name has a form "/message/flags/system/" Example: C: a FETCH 1 (MODTIME ("/message/comment" "/message/flags/system/$MDNSent")) S: * 1 FETCH (MODTIME ("/message/comment" 112 "/message/flags/system/$MDNSent" 64)) S: a OK Fetch complete 4.3 MODTIME criterion in SEARCH The MODTIME criterion for the SEARCH command allows a client to search for the specified modtime of a metadata item in a message. MODTIME Messages that have modification counter for metadata item with value equal or greater than . This allows a client, for example, to find out which messages contain metadata items that have changed since the last time it updated its disconnected cache. Examples: C: a SEARCH MODTIME "/message/flags/system/\\draft" "20010320162338" ANNOTATION "/message/comment" "value" "IMAP4" S: * SEARCH 2 3 5 7 11 13 17 19 23 S: a OK Search complete In the above example, the message numbers of any messages containing the string "IMAP4" in the "value" attribute of the "/message/comment" entry and having modtime "20010320162338" for flag \Draft are returned in the search results. 5. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [IMAP4]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. store = "STORE" SP set SP store-modifiers store-att-flags store-modifiers = [ "(" 1*store-modifier ")" ] store-modifier = "UNCHANGEDSINCE" time fetch-att =/ fetch-modtime ; modifies original IMAP4 fetch-att fetch-modtime = "MODTIME" SP "(" 1*attr-name ")" fetch-mod-resp = "MODTIME" SP "(" 1*(attr-name SP counter) ")" search-key =/ search-modtime ; modifies original IMAP4 search-key search-modtime = "MODTIME" SP attr-name SP counter resp-text-code =/ "MODIFIED" SP set attr-name = "/message/flags/system/" attr-flag ;; each system or user defined flag is mapped to ;; "/message/flags/system/" <> attr-flag = "\\Answered" / "\\Flagged" / "\\Deleted" / "\\Seen" / "\\Draft" / attr-flag-keyword / attr-flag-extension ; Does not include "\Recent" attr-flag-extension = "\\" atom ; Future expansion. Client implementations ; MUST accept flag-extension flags. Server ; implementations MUST NOT generate ; flag-extension flags except as defined by ; future standard or standards-track ; revisions of this specification. attr-flag-keyword = atom <> time = <"> time-year time-month time-day time-hour time-minute time-second time-subsecond <"> ;; Timestamp in UTC time-day = 2DIGIT ;; 01-31 time-hour = 2DIGIT ;; 00-23 time-minute = 2DIGIT ;; 00-59 time-month = 2DIGIT ;; 01-12 time-second = 2DIGIT ;; 00-60 time-subsecond = *DIGIT time-year = 4DIGIT 6. Security Considerations There are no known security issues with this extension. 7. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. [ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension", work in progress. [SORT-EXT] Crispin, M., "Internet Message Access Protocol -- SORT Extension", work in progress. 8. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. --------------618C9223199BC40ADC23A60F--