[MORG] draft-ietf-morg-multimailbox-search-04.txt: open issues

[Alexey Melnikov <[e-mail]>]

Hi,
Commenting on the remaining open issues in the document:

>    Interaction with IMAP Contexts [RFC5267] needs to be defined.
>    Comment from Timo:
>    I guess server then just has to monitor all matched mailboxes and
>    send updates whenever they happen.

I am thinking that this is going to be too much of a burden. CONTEXT=* 
can only operate on the current mailbox and there is already some text 
saying that the server can implement the limit on the number of 
outstanding UPDATE contexts. It would be too easy to deny service by 
allowing UPDATE contexts on each mailbox a user has, especially if there 
are lots of mailboxes.

To be more specific:

The CONTEXT return option (Section 4.2 of RFC 5267) can be used with a 
multimailbox search. It is only a hint to the server anyway.

The UPDATE return option (Section 4.3 of RFC 5267) can be used , but it 
should only apply to the currently selected mailbox, if any. I think 
usage of this option if there are no open mailboxes should cause a BAD 
tagged response.

The PARTIAL search return option (Section 4.4 of RFC 5267) can be used 
and will apply to each mailbox. 

> But should it notice newly
>    created/renamed mailboxes?

I think the answer here is no, because CONTEXT=SEARCH/CONTEXT=SORT were 
only designed to operate on the currently opened mailbox.

> Maybe the answer is no, except if NOTIFY
>    is also used (see below).
>
>    Suggestion: UPDATE option of IMAP Notify [RFC5465] might have to be
>    prohibited when both Context and this extension are used.  [Barry:
>    But why?  Isn't this then the equivalent of doing many SEARCH
>    commands with the UPDATE option?]

I am Ok with allowing the UPDATE option, assuming that it only applies 
to the currently selected mailbox. Note that the server can still refuse 
to create a persistent search as specified in Section 4.3.1 of RFC 5267.

>    Comment from Timo:
>    I guess the problem is if NOTIFY's extended UPDATE should be allowed.
>    Sending FETCH replies for messages matching in non-selected mailboxes
>    wouldn't work.  But the solution could be just that the FETCH replies
>    are sent only to messages in selected mailbox, whichever it happens
>    to be at the time changes happen.

I think this is sensible.

>    Comment from Barry:
>    Does anyone have other comments here?  Can anyone suggest text, if
>    there's text that needs to be added?
>
>    There's a suggestion to add an EXCLUDE clause (with a nested search
>    criteria).  For example, one might want to search "personal" but
>    exclude "mailboxes (Trash Spam)".
>    Cyrus suggests you can use metadata to tag mailboxes that you do or
>    don't want to search, and use search criteria to exclude them (good
>    for mailboxes that you NEVER want searched (as Trash and Spam,
>    above)).
>    Comment from Timo:
>    Dunno.  A 3rd possibility would be to make the IN a search-key, but
>    perhaps that would make things too complex again.  It would anyway
>    allow e.g.: ESEARCH unseen IN (personal) NOT IN (mailboxes "Spam"
>    subtree "Trash")
>    Comment from Barry:
>    My sense here is that we can (and should) defer this to a future
>    extension, if it turns out to be needed.  My sense is that it isn't
>    strongly needed.

Agreed.