Strawman: CONDSTORE (conditional STORE extension for flags/annotations)

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

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

Fwd: Agenda for IMAPEXT

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 <at> ietf.org
From: Pete Resnick <presnick <at> qualcomm.com>
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:presnick <at> qualcomm.com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

Modifying ANNOTATE modtime attribute in APPEND/STORE

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

Alexey

Reverse sort bug?

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 

Re: Reverse sort bug?

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:

re: Reverse sort bug?

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

Re: Reverse sort bug?

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

Re: Reverse sort bug?

--On Saturday, December 16, 2000 10:28 PM -0500 Ken Murchison 
<ken <at> oceana.com> 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

re: Reverse sort bug?

--On Saturday, December 16, 2000 2:11 PM -0800 Mark Crispin 
<MRC <at> cac.washington.edu> 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 

SORT wish list

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