Subject: RE: [lemonade] Re: New draft: SEARCH return options

From: [email-masked]
Date: Mon, 14 Feb 2005 15:19:10 -0600

> If you want ESEARCH to be bound to the command, you can 
> either use the 
> IMAP tag mechanism or reinvent it.
> 

Maybe not reinvent, but rather exploit.

To reuse Cyrus's example ...

C: a SEARCH RETURN (ALL) UNSEEN
C: b SEARCH RETURN (ALL) DELETED
S: * ESEARCH TAG a ALL 1:100,200:1000
S: * ESEARCH TAG b ALL 150
S: a OK
S: b OK

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

---

From: [email-masked]
Date: Mon, 14 Feb 2005 15:12:22 -0600

> On Mon, 14 Feb 2005, Cyrus Daboo wrote:
> > Can you explain with some examples...
> 
> tag SEARCH extended-poop
> tag OK [SEARCH extended-poop-response] extended SEARCH OK
> 
> as opposed to
> 
> tag SEARCH extended-poop
> * ESEARCH extended-poop-response
> tag OK SEARCH completed

Would there be any other reason then the pipelining id problem 
to do it this way?

Mike

---

From: [email-masked]
Date: Mon, 14 Feb 2005 15:45:51 -0600

> then the most honest response format is
> 
> a1234 ESEARCH ALL 1:100

I disagree. 

The notion of having multiple responses with tag affinity 
is perfectly valid in my mind. Given that, a logical progression 
from what you are proposing is ...

1 SEARCH ...
1 ESEARCH ...
1 SOME FUTURE RESPONSE ....
1 OK ...

In my mind this is a much more ungainly solution then to just reuse
the already existing notion of untagged solicited responses. Just
add tag affinity with a data item in the response is much simpler
and elegant.

Mike