wasm-demo/demo/ermis-f/imap-protocol/cur/1600095174.22920.mbox:2,S

41 lines
1.9 KiB
Plaintext

MBOX-Line: From snowjn at aol.com Wed Mar 14 11:46:41 2007
To: imap-protocol@u.washington.edu
From: John Snow <snowjn@aol.com>
Date: Fri Jun 8 12:34:38 2018
Subject: [Imap-protocol] SEARCH restricted to one mailbox? Extensions?
In-Reply-To: <45F83CCD.2050808@isode.com>
References: <07Mar12.152936pst."57996"@synergy1.parc.xerox.com> <1173743673.9167.65.camel@hurina>
<45F6A2E4.3060502@aol.com> <45F83CCD.2050808@isode.com>
Message-ID: <45F84311.3080906@aol.com>
alexey.melnikov@isode.com wrote:
> John Snow wrote:
>
>> How about combining the multiple mailbox search with a select command
>> to create a temporary mailbox view that contains the search result?
>> Since it doesn't exists as a listable mailbox, then it can't be the
>> destination for a copy command, avoiding any issue of which
>> underlying mailbox should be the destination. The untagged exists
>> response response would show the number of hits to the search query.
>> Also, the result set could be referenced by sequence number instead
>> of the individual UIDs as returned by the standard search command.
>
> This looks similar to VFOLDER extension:
> <http://tools.ietf.org/html/draft-ietf-lemonade-vfolder-01>
>
Sort of. In vfolder, the search criteria is stored to create a view
that is a subset of an existing mailbox. In that case, it can easily be
treated the same as any other mailbox. My hope is to expand that beyond
a single mailbox. I think creating a server stored view is
unnecessary. The extension aware client can create the combined view on
the fly. I see it more as an extension to search than a new virtual
mailbox. In a standard search, the results are only updated when the
client issues a new search and not pushed from the server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20070314/f64aa600/attachment.html>