Re: New draft: SEARCH return options

[Philip Guenther <[e-mail]>]

[Not sent to lemonade.  Do we really need to carry on this discussion in
both places?]

Cyrus Daboo <[e-mail]> writes:
...
>There is also an interesting possibility of tying the two together via the 
>ID return option I proposed. For example:
>
>C: a SEARCH RETURN (ID 1 ALL) UNSEEN
...
>C: FETCH $[1] (UID INTERNALDATE FLAGS RFC822.HEADER)
...
>The fetch commands act on the result of the different searches, referenced 
>by the ID option value. This means that a client could use multiple search 
>result sets simultaneously, as opposed to in series, as they would have to 
>right now.

The '$' token in draft-melnikov-imap-search-res-01.txt references the
last SEARCH result, so it only requires the server to remember the one
such result.  If multiple search responses need to be remembered then
some limit needs to be placed on how many a client can expect a server
to remember and perhaps the client will need some way of controlling
their lifetime.


Philip Guenther