Subject: [lemonade] RE: Comments/questions about MSGFILTER

From: [email-masked]
Date: Sun, 7 Nov 2004 18:37:34 -0600

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Sunday, November 07, 2004 1:44 PM
...
> I think the extension is lacking the ability to list 
> available external 
> filters.

Yes. It was intentional. Since the management of the filters, i.e. there definition, 
was opaque to the protocol I thought it better to be consistent. I could see how
it would be valuable to list them, though. Note that the logic of the criteria in the 
TAG filters is completely opaque to IMAP.

...
>  >    The rules of accumulation are:
>  >
>  >        1) TAG Sub-Commands MUST replace ALL previous Sub-Commands,
>  >           including previous TAG Sub-Commands.
>  >        2) New SEARCH sub-commands MUST replace a previous SEARCH
>  >           Sub-Command. New SEARCH sub-commands MUST union 
> with previous
>  >           TAG commands.
> 
> Just to clarify: is SEARCH performed only once (when the command is 
> issued) or it is done every time a new message arrives?

I assume you are talking about the implementation. The semantics require the
criteria to be applied to each new message. This is not the same as executing
an entire new SEARCH command.

In the case of accumulation each FILTER SET command would require the
criteria to be applied to the entire folder.

...
>  >    An EXISTS response is sent as the first response in a 
> Filter Set. It
>  >    represents the total number of messages visible after the
>  >    application of the latest FILTER SET.
> 
> I suggest you define a new response instead.

Why? One of my goals was to try and minimize the additions/modifications 
to the protocol.

> 
>  >    Example:    C: 1 SELECT INBOX
>  >                S: * 50 EXISTS
> [...]
>  >                S: 3 OK FILTER SET Completed
>  >                C: 4 FETCH
> 
> The example seems to be truncated.

Yes.

...
>  >    The FILTERED response is returned when any command is issued in
>  >    the Selected state and the sequence or UID arguments 
> are sets that
>  >    may include numbers not explicitly asked for by the client.
> 
> Ok, you need to describe what would be the behavior of STORE/COPY 
> commands, when a filter is in effect. I would presume that STORE/COPY 
> are not affected. So effectively a filter only affects which FETCH 
> responses are to be returned? What about SEARCH?

The intent was to affect all commands that operate on messages. The result 
is that the client does not "see" excluded messages via any command while 
a FILTER SET is in effect.

The reason is to reduce the burden on the client. 

Mike

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 08 Nov 2004 12:49:06 +0000

[email-masked] wrote:

>>available external filters.
>>    
>>
>
If you want any kind of interoperability between multiple clients, you 
either need a command to list named filters, or there should be an 
official registry of filter names.

You've already mentioned a filter tag "DEFAULT". I think the document 
should at least mention it.

>I assume you are talking about the implementation.
>
No, I was actually asking if the FILTER SET SEARCH is static or dynamic. 
Dynamic means that any new message is evaluated against filter criteria 
and existing messages can drop out of the filter, for example if the 
filter search criteria depends on some flags that change.

> The semantics require the
I agree.

>Why? One of my goals was to try and minimize the additions/modifications 
I prefer not to overload existing responses.

Do you want the client to be notified about new message arrivals, even 
if the corresponding messages are filtered out?

>a FILTER SET is in effect.
The document must say so.
I frankly see no point of restricting STORE/COPY (especially UID 
STORE/COPY).

This also means that SEARCH would have to intersect the specified search 
criteria with the current filter?

>The reason is to reduce the burden on the client. 

One more question:
Does the filter go away when the selected mailbox is closed?

Alexey