Subject: [lemonade] [Fwd: I-D Action:draft-melnikov-imapext-filters-05.txt]

From: Alexey Melnikov <[email-masked]>
Date: Sat, 05 Jul 2008 19:07:02 +0100

Hi folks,
As per discussion in Philadelphia, draft-melnikov-imapext-filters is now 
a Lemonade WG draft.
I would like to request WGLC for the document really soon now, so any 
comments/reviews would be greatly appreciated.

Subject: I-D Action:draft-melnikov-imapext-filters-05.txt
From: [email-masked]
To: [email-masked]
Date: Sat, 5 Jul 2008 11:00:02 -0700 (PDT)
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IMAP4 extension for named searches (filters)
	Author(s)       : A. Melnikov, C. King
	Filename        : draft-melnikov-imapext-filters-05.txt
	Pages           : 14
	Date            : 2008-07-05

The document defines a way to persistently store named IMAP (RFC
3501) searches on the server.  Such named searches can be
subsequently referenced in a SEARCH or any other command that accepts
a search criteria as a parameter.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-imapext-filters-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Sun, 6 Jul 2008 01:16:02 +0530

On Jul 5, 2008, at 11:37 PM, Alexey Melnikov wrote:

> Hi folks,
> As per discussion in Philadelphia, draft-melnikov-imapext-filters is  
> now a Lemonade WG draft.
> I would like to request WGLC for the document really soon now, so  
> any comments/reviews would be greatly appreciated.

1) SETFILTER:
> If the filter parameter is not specified, the filter description is  
> set to the empty string.

What "filter parameter"? "filter description parameter"?

2) I'm not sure if I like having both /filters/ and /filter- 
descriptions/ reserved. Seems like there'd be less pollution if it  
instead was either:

a) /filters/values/<name> and /filters/descriptions/<name>

b) /filters/<name> and /filters/<name>/description

3) Also then there's the larger issue of SET/DELETE/LISTFILTERS  
commands even existing, since they would be unnecessary if FILTERS  
required METADATA and wildcards hadn't been dropped from its -13  
draft.. Doing it this way seems like unnecessary bloat to me. How many  
SET/DELETE/LIST* commands will we end up having in future?.. Reminds  
me of RLIST/RLSUB commands that got deprecated by LIST-EXTENDED. But  
if you really want to do it this way, I won't try to stop you.

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 9 Jul 2008 14:38:23 +0530

On Jul 6, 2008, at 1:16 AM, Timo Sirainen wrote:

> draft.. Doing it this way seems like unnecessary bloat to me. How  
> many SET/DELETE/LIST* commands will we end up having in future?..  
> Reminds me of RLIST/RLSUB commands that got deprecated by LIST- 
> EXTENDED. But if you really want to do it this way, I won't try to  
> stop you.

BTW. My preferred solution would be:

1. Change METADATA to not allow arbitrary key=value pairs by default.  
For servers that do allow them, advertise them somehow - maybe another  
capability.

2. Add wildcard support back to METADATA. If it's problematic with  
arbitrary keys, allow it only for specific registered metadata entries.

3. Have FILTERS require METADATA, make sure listing filters allows  
wildcards, drop SET/DELETE/LISTFILTERS commands.

This way the same METADATA commands can be used to read, modify and  
list the filters. If some servers don't want to support full METADATA,  
there should be no problems implementing the restricted version that  
basically exists to give the commands to manage filters. No more ugly  
unnecessary extra commands.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 09 Jul 2008 13:00:26 +0100

Hi Timo,
I will reply to your messages in more details later, but a quick note on 
this issue:

> wildcards, drop SET/DELETE/LISTFILTERS commands.

There was an earlier request from several people (including my 
co-author) to remove dependency on METADATA. This was partially 
motivated by a concert about METADATA deployability.
My latest version is trying to preserve compatibility with METADATA (or 
rather METADATA-SERVER), while allowing people to implement FILTERS 
without implementing METADATA[-SERVER].

> list the filters. If some servers don't want to support full 
> METADATA,  there should be no problems implementing the restricted 
> version that  basically exists to give the commands to manage filters. 
> No more ugly  unnecessary extra commands.

While the new commands might be unnecessary, I disagree that they are 
ugly :-).

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 9 Jul 2008 17:39:15 +0530

On Jul 9, 2008, at 5:30 PM, Alexey Melnikov wrote:

> Hi Timo,
> I will reply to your messages in more details later, but a quick  
> note on this issue:
>
> Timo Sirainen wrote:
>
> There was an earlier request from several people (including my co- 
> author) to remove dependency on METADATA. This was partially  
> My latest version is trying to preserve compatibility with METADATA  
> (or rather METADATA-SERVER), while allowing people to implement  
> FILTERS without implementing METADATA[-SERVER].

But were the concerns mainly about requiring to implement arbitrary  
key=value metadata? If that wasn't required, would the concerns go away?

For example perhaps this limpy METADATA implementation wouldn't even  
have to be announced as a capability. FILTERS would simply require  
using and implementing METADATA-compatible commands for accessing  
filters.

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 26 Jul 2008 20:51:18 +0100

> What "filter parameter"? "filter description parameter"?

Yes. I've updated my copy.

> b) /filters/<name> and /filters/<name>/description

I am not too sure about this. Any opinion, Cyrus?