Subject: [lemonade] Comments/questions about MSGFILTER

From: Alexey Melnikov <[email-masked]>
Date: Sun, 07 Nov 2004 18:43:36 +0000

>2.1 FILTER SET Command
 >  
 >    Arguments: OPTIONAL Sub-Command with arguments. The allowed sub
 >               commands are SEARCH,UID and TAG. The SEARCH command can
 >               be followed by all associated SEARCH arguments. The TAG
 >               command MUST be followed by an identifier. The UID sub
 >               command MUST be followed by one or more numeric numbers.
 >  
 >    Responses: REQUIRED untagged responses: FILTER SET and EXISTS
 >  
[...]  
 >    A FILTER SET command will restrict the set of UIDs that are visible
 >    to the client. The three forms allow the Filter Set to be changed
 >    during the session. The total Filter Set is an accumulation of all
 >    FILTER SET commands issued during the session. The accumulation is
 >    not a simple UNION.
[...]
 >    A TAG Sub-Command will result in a set of UIDs that match some
 >    external set of criteria. The argument pasted to the this Sub-
 >    Command is a Filter Set Indentifier.

I think the extension is lacking the ability to list available external 
filters.

 >    Multiple FILTER SET commands may be issued during a single session.
 >    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?

 >        3) UID Sub-Commands are always cumulative. Multiple UID ADD
 >           Sub-Commands will increase the Filter Set, while UID REMOVE
 >           Sub-Commands will reduce the Filter Set if the specified UID
 >           was already in the set.
 >
 >    Filter Sets are transient. A Filter Set only lasts for the duration
 >    of the Session. A new Session requires the re-establishment of the
 >    Filter Set.   
 >
 >    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.

 >    Example:    C: 1 SELECT INBOX
 >                S: * 50 EXISTS
[...]
 >                S: 3 OK FILTER SET Completed
 >                C: 4 FETCH

The example seems to be truncated.

 >3.1 FILTERED Response
 >
 >    While there are Filter Sets in effect in a session all normal IMAP
 >    commands are still legal. A FILTERED response is returned when
 >    issued to communicate to the client that the current set of
 >    responses are representative of a Filter Set and not the total set
 >    of messages that may have been returned had the Filter Set not been
 >    in effect.
 >
 >    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?

Alexey

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

---

From: [email-masked]
Date: Mon, 8 Nov 2004 08:23:42 -0600

> -----Original Message-----
> From: ext Alexey Melnikov [mailto:[email-masked]]
> Sent: Monday, November 08, 2004 7:49 AM
...
> >>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.
> >  
> >
> If you want any kind of interoperability between multiple 
> clients, you 
> either need a command to list named filters, or there should be an 

I can see a use for this.

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

Agreed.

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

But it is not overloading. I'm attaching the same meaning.

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

No. This is one difference between XFILTER and FILTER SET.

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

Yes.

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

The Filter Set always does. Non-TAG Filters also do.

The Filter Set being the UIDs that result from the application 
of the criteria. The Filter being the criteria them selves.

Mike