Subject: [MORG] multimailbox comments

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Jan 2009 13:19:40 +0100

1. Shouldn't a multimailbox search (the only kind that's relevant to 
this document) always return ESEARCH, never SEARCH?

2. The mailbox correlator needs UIDVALIDITY.

3. I see no value in DEPTH. It wouldn't be so very difficult for me to 
implement, but I see no point in doing it. Mark would say "neat to 
have".

4. I'm neutral on borrowing mailbox syntax from Notify.

5. Is the eventual capability name supposed to be MMBX? Why?

Arnt
_______________________________________________
MORG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/morg
Note Well: http://www.ietf.org/maillist.html

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jan 2009 12:23:22 +0000

> this document) always return ESEARCH, never SEARCH?

Yes.

> 2. The mailbox correlator needs UIDVALIDITY.

Ok.

> implement, but I see no point in doing it. Mark would say "neat to have".
>

I am still thinking about these 2.

> 5. Is the eventual capability name supposed to be MMBX? Why?

Because MULTIMAILBOXSEARCH is long. But I am open to suggestions.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Jan 2009 13:31:21 +0100

> Because MULTIMAILBOXSEARCH is long. But I am open to suggestions.

MMSEARCH maybe. But I don't really care. MMBX is okay. Surprised me.

Just make sure you say what it is to be. The document as it stands 
doesn't actually say that, it only names the X-THIS-AND-THAT wart.

6. I think the client usually needs both l and r to use multimailbox 
search: l in order to do the glob, r in order to do the search.

7. Multimailbox search doesn't permit any kind of ACL error. All ACL 
errors are silently ignored. I think that's fine, but perhaps it should 
be stated explicitly.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Jan 2009 14:30:21 +0100

> 4. I'm neutral on borrowing mailbox syntax from Notify.

I'm implementing.

I don't like LIST and its globbing. It brings too many problems for its 
value, there are ten corner cases for every use case, and there's a 
fresh new problem every year. (No insult intended, Mark. IMAP has many 
good features, and noone can expect you to get it right every time.)

AFAICT the use cases for multimailbox search involves searching some 
subtree of mailboxes. Occasionally someone mentions searching several 
subtrees, or even "all mailboxes I can read".

Therefore, my preference would be for multimailbox search to take a list 
of mailbox names, treat it as a list of subtree roots, search all 
(l)r-able mailboxes in those subtrees, and ignore other mailboxes.

That covers what I need, what people tell me they need (but I don't 
entirely trust), is easy for me to implement, and doesn't perpetuate 
LIST's globbing.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 26 Jan 2009 10:30:47 -0500

What are people's thoughts in using views instead of SEARCH IN? The
views have 3 major advantages that I can see:

1) They're really easy to implement by existing clients. In fact if the
view is already created (e.g. a default view by admin) the client
requires no support at all to be able to use it, since it would show up
as a regular mailbox.

2) Reduces roundtrips that are required to fetch information about
messages that were found.

3) Clients don't need special code for noticing and handling UIDVALIDITY
changes between SEARCH and SELECT/FETCH.

I wrote about my plans a couple of months ago, but there were no
replies: http://www.ietf.org/mail-archive/web/morg/current/msg00078.html

I could start writing a (yet another) draft about views, but I won't
bother if no one else has interest in implementing them.
_______________________________________________
MORG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/morg
Note Well: http://www.ietf.org/maillist.html

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Jan 2009 15:40:03 +0000

>replies: http://www.ietf.org/mail-archive/web/morg/current/msg00078.html
It is hard for me to make a choice, because I don't have enough details.

>bother if no one else has interest in implementing them.
I would suggest you write a draft that at least demonstrates (using 
examples) all features you want to add to the protocol. I hope this 
would be less work that describing your proposal in details.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 26 Jan 2009 16:44:23 +0100

> views have 3 major advantages that I can see:

Do you mean snapshot views or dynamic ones?

> bother if no one else has interest in implementing them.

I could do that easily. I don't mind one way or the other.

But I do want something that goes away, something unnamed. Named views 
tend to stay around for a while and be updated many times. Polluting 
that with temporary searches is a pain.

So I want something that a client can run to look at the results once. 
Perhap a new argument to SELECT that makes it create a new session on 
the result of a search, instead of on a new mailbox. Or something.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Jan 2009 11:10:01 -0500

Timo says...
> views have 3 major advantages that I can see:

Cyrus calls "views" "something of a rathole".  I like Cyrus's nicely understated 
manner, don't you?

Arnt says...
> But I do want something that goes away, something unnamed. Named views tend to
> stay around for a while and be updated many times. Polluting that with
> temporary searches is a pain.
>
> So I want something that a client can run to look at the results once. Perhap a
> new argument to SELECT that makes it create a new session on the result of a
> search, instead of on a new mailbox. Or something.

Arnt starts to get at *why* this isn't so much a "rathole" as a black hole of a 
size astronomers have yet to comprehend.

Arnt and Timo weren't around during the Great View Wars, but you can look at the 
archives.  The gist of it is that everyone knows what Views should do, to a first 
approximation, and everyone agrees that they're great, answer all our questions, 
create peace in the middle east, and let us all live in the lap of luxury for 
175-year life spans.

The problem is that when we get past the first approximation, it becomes 
surprisingly complex and leads to wild disagreements about what should happen. 
Is the view static or dynamic?  What happens when new messages arrive?  What 
happens when existing messages change stat to enter or leave the criteria that 
define the view?  Should a view subset a single mailbox, or allow a virtual view 
that spans mailboxes?  How does that work with ACLs, referrals, and such?  Etc, 
etc....

Note that I'm not asking anyone to answer the questions in the previous 
paragraph: the problem is that we'll all have different answers, and we'll all be 
right, for one scenario or another.  And every answer will create a different 
implementation complexity issue, both for the server vendors and for the client 
vendors.

I'm not saying that we'll never solve it and come up with something that we can 
all live with, or even be happy with.  But Cyrus is right that unless we have 
*several* clients that will implement it and who can guide us on *real* 
requirements, so that we come up with answers to all these issues that make it 
*usable* in the real world, there's no point in approaching the event horizon.

Barry

--
Barry Leiba, Senior Technical Staff  ([email-masked])
Internet Messaging Technology, IBM Research
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 26 Jan 2009 13:57:14 -0500

> Do you mean snapshot views or dynamic ones?

Either one would be fine with me. Both would work for multi-mailbox
search. Dynamic ones would of course provide more functionality.

> that with temporary searches is a pain.

Sure. Although I'd think most clients simply want "search from all
mailboxes" which would require just one permanent name.

> the result of a search, instead of on a new mailbox. Or something.

I think I also suggested that at some point :) Or not search parameters,
but just a list of mailboxes that could be SELECTed and then SEARCH
could be used inside them. That would also avoid double search if you
want to do SORT / THREAD.
_______________________________________________
MORG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/morg
Note Well: http://www.ietf.org/maillist.html

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 26 Jan 2009 14:05:54 -0500

> implementation complexity issue, both for the server vendors and for the client 

That's why I'm not really thinking about making views that solve
everything for everyone (although I wouldn't really mind that either, as
Dovecot already has most of that implemented :), but instead make the
views just enough to easily allow multi-mailbox searches, maybe also
keeping in mind how a future complex view specification might work.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 27 Jan 2009 13:14:24 +0100

> search. Dynamic ones would of course provide more functionality.

Either would be fine with me; dynamic possibly a little simpler.

>> But I do want something that goes away, something unnamed. Named 
>> views tend to stay around for a while and be updated many times. 
>> Polluting that with temporary searches is a pain.
>

As long as it's one, OK.

Btw, if there's just one name per user, then two clients could get in 
each other's way. Although I suppose that won't matter much, since the 
user tends to use just one at a time.

>>  So I want something that a client can run to look at the results 
>>  once. Perhap a new argument to SELECT that makes it create a new 
>>  session on the result of a search, instead of on a new mailbox. Or 
>>  something.
>
> I think I also suggested that at some point :)

Fine.

> Or not search parameters, but just a list of mailboxes that could be 
> SELECTed and then SEARCH could be used inside them. That would also 
> avoid double search if you want to do SORT / THREAD.

I like that less. Everyone concerned would have to deal with a large 
intermediate set, and the UIDs would lose most of their desirable 
properties.

Arnt