Subject: re: SORT wish list
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Fri, 22 Dec 2000 22:38:02 -0800 (PST)
List-Id: <ietf-imapext.imc.org>

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.

Date: Fri, 22 Dec 2000 22:23:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Tue, 19 Dec 2000 12:43:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Monday, December 18, 2000 5:32 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 17:32:28 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 18 Dec 2000 19:24:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Monday, December 18, 2000 3:46 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 15:46:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 18 Dec 2000 12:10:07 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT wish list
Sender: [email-masked]

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

Date: Mon, 18 Dec 2000 11:29:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

--On Saturday, December 16, 2000 10:28 PM -0500 Ken Murchison 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 11:28:17 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Saturday, December 16, 2000 2:11 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Sat, 16 Dec 2000 22:28:38 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

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

Date: Sat, 16 Dec 2000 14:11:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

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?).

Date: Sat, 16 Dec 2000 17:07:20 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

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

Date: Sat, 16 Dec 2000 14:35:46 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>, Mark Crispin <[email-masked]>
cc: Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Reverse sort bug?
Sender: [email-masked]

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

Date: Fri, 15 Dec 2000 00:18:54 -0800
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Randall Gellens <[email-masked]>
Subject: Modifying ANNOTATE modtime attribute in APPEND/STORE
Sender: [email-masked]

Can a client specify modtime attribute in APPEND?
What about STORE?

Alexey

Date: Thu, 14 Dec 2000 08:19:54 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Fwd: Agenda for IMAPEXT
Sender: [email-masked]

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: [email-masked]
From: Pete Resnick <[email-masked]>
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 <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 13 Dec 2000 09:41:36 -0800
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Strawman: CONDSTORE (conditional STORE extension for flags/annotations)
Sender: [email-masked]

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

   <<To be completed later>>

1. Abstract
    
   <<To be written later. Proposals are welcome>>

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 <attr-names>

        The MODTIME message data item, when used by the client in the
        FETCH command, takes a list of metadata items.  For a flag
        <flagname> the corresponding attr-name has a form
        "/message/flags/system/<flagname>"
    
    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 <attr-name> <modtime-value>

            Messages that have modification counter for metadata item
            <attr-name> with value equal or greater than
            <modtime-value>. 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 <flag> is mapped to
                        ;; "/message/flags/system/<flag>"

<<Borrowed from IMAP4rev1 and modified accordingly:>>

   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

<<Borrowed from ACAP:>>

   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.
    <ftp://ftp.isi.edu/in-notes/rfc2244.txt>

    [ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
    work in progress.
    <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>

    [SORT-EXT] Crispin, M., "Internet Message Access Protocol -- SORT
    Extension", work in progress.
    <http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-xx.txt>

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--

Date: Fri, 22 Dec 2000 22:38:02 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: SORT wish list
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 22 Dec 2000 22:23:45 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Tue, 19 Dec 2000 12:43:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Monday, December 18, 2000 5:32 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 17:32:28 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 18 Dec 2000 19:24:04 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Monday, December 18, 2000 3:46 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 15:46:42 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Sender: [email-masked]

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.

Date: Mon, 18 Dec 2000 12:10:07 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: SORT wish list
Sender: [email-masked]

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

Date: Mon, 18 Dec 2000 11:29:01 -0500
From: Cyrus Daboo <[email-masked]>
To: Ken Murchison <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

--On Saturday, December 16, 2000 10:28 PM -0500 Ken Murchison 
<[email-masked]> 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

Date: Mon, 18 Dec 2000 11:28:17 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>
Subject: re: Reverse sort bug?
Sender: [email-masked]

--On Saturday, December 16, 2000 2:11 PM -0800 Mark Crispin 
<[email-masked]> 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

Date: Sat, 16 Dec 2000 22:28:38 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

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

Date: Sat, 16 Dec 2000 14:11:55 -0800 (PST)
From: Mark Crispin <[email-masked]>
Subject: re: Reverse sort bug?
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Sender: [email-masked]

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?).

Date: Sat, 16 Dec 2000 17:07:20 -0500
From: Ken Murchison <[email-masked]>
Organization: Oceana Matrix Ltd.
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Mark Crispin <[email-masked]>, Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Re: Reverse sort bug?
Sender: [email-masked]

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

Date: Sat, 16 Dec 2000 14:35:46 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Ken Murchison <[email-masked]>, Mark Crispin <[email-masked]>
cc: Walter Wong <[email-masked]>, Lawrence Greenfield <[email-masked]>
Subject: Reverse sort bug?
Sender: [email-masked]

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

Date: Fri, 15 Dec 2000 00:18:54 -0800
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
CC: Randall Gellens <[email-masked]>
Subject: Modifying ANNOTATE modtime attribute in APPEND/STORE
Sender: [email-masked]

Can a client specify modtime attribute in APPEND?
What about STORE?

Alexey

Date: Thu, 14 Dec 2000 08:19:54 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Fwd: Agenda for IMAPEXT
Sender: [email-masked]

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: [email-masked]
From: Pete Resnick <[email-masked]>
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 <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Date: Wed, 13 Dec 2000 09:41:36 -0800
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Strawman: CONDSTORE (conditional STORE extension for flags/annotations)
Sender: [email-masked]

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

   <<To be completed later>>

1. Abstract
    
   <<To be written later. Proposals are welcome>>

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 <attr-names>

        The MODTIME message data item, when used by the client in the
        FETCH command, takes a list of metadata items.  For a flag
        <flagname> the corresponding attr-name has a form
        "/message/flags/system/<flagname>"
    
    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 <attr-name> <modtime-value>

            Messages that have modification counter for metadata item
            <attr-name> with value equal or greater than
            <modtime-value>. 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 <flag> is mapped to
                        ;; "/message/flags/system/<flag>"

<<Borrowed from IMAP4rev1 and modified accordingly:>>

   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

<<Borrowed from ACAP:>>

   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.
    <ftp://ftp.isi.edu/in-notes/rfc2244.txt>

    [ANNOTATION] Gellens, R., Daboo, C., "IMAP ANNOTATE Extension",
    work in progress.
    <http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-xx.txt>

    [SORT-EXT] Crispin, M., "Internet Message Access Protocol -- SORT
    Extension", work in progress.
    <http://www.ietf.org/internet-drafts/draft-crispin-imapext-sort-xx.txt>

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--