Subject: [lemonade] Draft Minutes, Interim Day 1

From: "Burger, Eric" <[email-masked]>
Date: Thu, 1 Jun 2006 09:01:17 -0400

Posted to http://www3.ietf.org/proceedings/06jul/minutes/lemonade.txt

Draft Minutes, lemonade Interim Meeting 65,5
31 May 2006

Chairs:
Eric Burger
Glenn Parsons

Attendees:
Alexey Melnikov
Arnt Gulbrandsen
Ray Cromwell
Dave Cridland
Greg Vaudreuil
Mike Parsel
Ken Murcheson
Jerry Shih
Stephane Maes

Jabber Logs
31 May 2006: http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html

Meeting Goal: Get updates to documents by 19 June 2006 in time for WGLC before or at IETF 66 in Montreal.

Draft Discussions
=================

RECONNECT
---------
Issue: Do we need to mandate a minimum number of outstanding sessions a server must support?
Discussion: Could make clients easier to implement if they knew that a server would have at least so many sessions available.
Rejoinder: No matter what, another client can consume sessions, so the client must have code to deal with exhaustion of session resources.  Thus there is no benefit of having a preset minimum number of sessions available for reconnect.
Result: Be silent on a minimum number of sessions.

Issue: Do we need server-side RECONNECT?
Discussion:  RECONNECT authors realized the tokens being passed to let the server know which session was being reconnected was identical to the state the server needed to know to re-establish state.  Thus it is possible for the server to be stateless.
This follows IETF practice of avoiding fate sharing.  The client holds the state, and if the client fails, it doesn't care the state is lost, as it lost the state anyway.  The proposal does not add any burden on clients, as the client needed to store the same information with the server-driven scheme.
Rejoinder: Server-driven document is already written; do we want to delay?
Result: Create new document centered around client-driven RECONNECT.  It will be a work group document: draft-ietf-lemonade-reconnect-client; we are confident in its status as only about 2 paragraphs change.  After the new draft is issued and the old draft is updated (there are some ABNF issues, etc. that need to be addressed), we will preferably chose one document and kill the other.  Alternately, we will chose one, reference it in Profile-bis, and release the other as Experimental.  Worst-case is both documents progress.

IMAP URL (2192-bis)
-------------------
Issue: Alexey needs Mark's input to decide what goes into 2192-bis versus URLAUTH.
Resolution: Alexey will e-mail Mark directly.

Issue: Should 2192-bis include examples of extensions from BINARY, URLFETCH, imap-search-ret?
Resolution: If those drafts are stable, then yes, otherwise, no.  Alexey will send note to list if he doesn't get a response, then he will assume the drafts are not stable.

CONVERT
-------
Issue: ISO-8859-n has 16 values for n.  Which one(s) do we mandate?
Resolution: All of them (?).  Clearly at least ISO-8859-1 (trivially easy) and ISO-8859-5 (in honor of Alexey) will be mandatory to implement.

Issue: The original draft had a bunch of conversions that are now not mandatory.
Resolution: Leave the text, but change RFC 2119 language from MUST/SHOULD to MAY.  Note that OMA will impose relevant mandatory-to-implement conversions.  We will ensure the protocol can handle them, but will not mandate any particular conversions outside of ISO-8859-n to UTF-8.

COMPRESS
--------
Note: There are some very interesting results discussed in the Jabber log <http://www3.ietf.org/meetings/ietf-logs/lemonade/2006-05-31.html>, around the 12:20 time mark, about compression experiment results for TLS and compress=deflate.  The short of it is that traffic with a moderate amount of attachments gets 70% compression using TLS; traffic with lots of attachments gets better compression with compress=deflate.

Issue: How to disambiguate Content-Transfer-Encoding from Content-Type?
Discussion: VPIM experience is the C-T-E is not well supported.  One proposal is to use magic MIME types.
Rejoinder: Only a C-T-E knowledgeable client will request compression from a C-T-E knowledgeable server.  Moreover, using C-T-E is a correct protocol thing to do, as in "say what we mean."
Reminder: The server is in the best position to decide whether or not to compress (if compression accepted by the client).  The client-driven use case, where the client wants to save CPU at the expense of radio power, does not match the physics of the situation. 
Discussion: Propose compress=deflate (draft-arnt-imap-deflate-02).  Unquestionable desire to NOT have the mechanism be on a request-per-body-part basis.  However, there is also a desire to have the mechanism be controllable (on or off) at client-requested point in the session.
Discussion: Although deflate is the compression algorithm of gzip, and the proposed lemonade mechanism was called gzip, we are NOT discussing using gzip anymore.  This means that the stream will not include the actual MIME type or file name (as would happen if we used the entire gzip structure).
Discussion: Clear win for downstream (server->client) compression.  However, compression could be a cost for upstream messages, as the protocol messages are often smaller than the PDU of the compressed block.
Discussion: What, if in the middle of a transaction, the client says, "stop compressing"?  That isn't a problem, because the IMAP transaction model says the current transaction completes.
Resolution: Move compress out of convert document.  Use compress=deflate.  Ensure the method is controllable.  Ensure the method can be asymmetric (compress one way and not the other).
Arnt is to be lead author.
Special note: we will re-use the name draft-ietf-lemonade-compress-04, but the contents will be entirely deleted and the new content will substantially come from draft-arnt-imap-deflate-02.

ENCRYPT
-------
Issue: Still not clear what the business / use case is for this feature.  Needs to be clear and distinct.
Discussion: Classic industry problem: if we don't do it, someone less knowledgeable will do it.
Resolution: new draft coming.

WITHIN
------
Issue: Second recalculation is way too much of a server burden.
Discussion: We are not trying to replicate instant messaging.  Daily is enough.  Hourly is OK.
Resolution: Hourly it is.

Issue: Should we give guidance on recomputing views?
Resolution: Yes, put in an informative section into the document.

VFOLDER
----¬---
Issue: Anonymous users creating VFOLDERs can be a DoS attack.
Resolution: Anonymous users cannot create a VFOLDER, but they can read them.

Issue: Legacy clients might duplicate messages since they don't know the messages are virtual.
Reminder: In Dallas (and on the list) we said that only lemonade clients could use VFOLDERs.
Discussion: Would be very useful for legacy clients to see VFOLDERs.
Resolution: Allow VFOLDER only for lemonade clients for now.

Issue: What happens if one renames a folder a VFOLDER depends on?
Discussion: Original proposal is to delete the VFOLDER.
Rejoinder: That would be a customer service nightmare - all of my folders disappeared?!?!
Resolution: VFOLDER calculations get updated when one renames an underlying VFOLDER.

Issue: Can we have a VFOLDER that is the set of messages that are not selected by any other VFOLDER?
Resolution: Submit text.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 01 Jun 2006 14:46:55 +0100

>Draft Minutes, lemonade Interim Meeting 65,5
Some minor additions/corrections.

>IMAP URL (2192-bis)
I also need some help with sections talking about listing content of a 
server and mailbox naming scope. I think Dave has volunteered for that.

>Resolution: If those drafts are stable, then yes, otherwise, no.  Alexey will send note to list if he doesn't get a response, then he will assume the drafts are not stable.
[...]

>Resolution: new draft coming.
But this is not going to be included in Lemonade Phase 2. (If my memory 
doesn't fail me)

>Resolution: VFOLDER calculations get updated when one renames an underlying VFOLDER.
"when one renames an underlying mailbox"

---

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Jun 2006 11:09:16 -0700

>  Draft Minutes, lemonade Interim Meeting 65,5

I was there (a bit late due to Chicago weather).
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
When news of Alexander Graham Bell's invention reached the
United Kingdom, the chief engineer of the British Post Office
failed to be impressed.  "The Americans," he said loftily,
"have need of the telephone -- but we do not.  We have plenty
of messenger boys..."

---

From: Randall Gellens <[email-masked]>
Date: Thu, 1 Jun 2006 11:23:41 -0700

>  Issue: Legacy clients might duplicate messages 
> since they don't know the messages are virtual.
>  Reminder: In Dallas (and on the list) we said 
> that only lemonade clients could use VFOLDERs.

How are legacy clients barred from SELECTing vfolders?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Rank of Catwoman among the "superheros" American boys under the
age of ten say they would most like to be: 1.
                                              --(Harper's Index)

---

From: Curtis King <[email-masked]>
Date: Thu, 1 Jun 2006 13:26:11 -0600

> How are legacy clients barred from SELECTing vfolders?

If we are going to-do this then why keep the mailbox framework?  
VFOLDER currently has a number of show stoppers already:

1. duplicate messages.
2. message going into and out of focus.
3. UID issues caused by 1 and 2.
4. Do you delete messages when you delete the VFOLDER? According to  
the draft it is supposed to behave like a real mailbox.

Why not have filters you can apply to mailbox?

ck

---

From: Curtis King <[email-masked]>
Date: Thu, 1 Jun 2006 14:28:33 -0600

> Why not have filters you can apply to mailbox?

Sorry, this needs more detail.

Why not have a draft which treats filters as filters instead of  
mailboxes? I understand using the mailbox metaphor has lots of  
appeal, but users and MUAs expect if not rely on specific mailbox  
behaviors which are hard to reproduce using VFOLDER.

I still think the best idea is from Cyrus:

--------
Instead, what I would propose for clients being able to 'run  
scripts', is a combination of the following:

1) Enhance the SEARCH command with better comparators (globbing,  
regex etc)

2) Introduce a 'pipe' operation that will allow the result set of the  
last (or named) search command to be fed into a subsequent fetch/ 
store. I think there was already a proposal for that.

3) Introduce a 'macro' facility that would allow clients to define  
commonly used commands via a keyword and store those on the server,  
and then execute the commands via the keyword. This would allow for  
'saved searches' - frequently used search commands stored on the  
server that can be quickly executed without having to uplaod the  
search each time. Anyone who has written a client that attempts to do  
traditional mua filtering using IMAP search will appreciate the  
benefit of something like that. These 'macros' could execute more  
than one command at a time with some limitations. e.g. a UID SEARCH  
followed by a UID COPY, followed by a UID STORE, followed by a UID  
expunge would emulate an mua filter action that could move messages  
matching certain criteria to another mailbox.
-------

You could get VFOLDER behavior by piping a search to select.

ck

---

From: Dave Cridland <[email-masked]>
Date: Thu, 01 Jun 2006 23:39:07 +0100

> How are legacy clients barred from SELECTing vfolders?

They're not, but they're prevented from listing them without being 
asked with special LIST-EXTENDED selection options.

I think this is a mistake, actually, because you're preventing legacy 
clients from taking advantage of them, which I think is a key feature 
of virtual mailboxes.

I appreciate that some dumb clients download every message in every 
mailbox, but I fail to see the point of crippling the system to 
pander for clients that are badly written to begin with - you could 
equally well say that IMAP servers should hide more than 10 mailboxes.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 2 Jun 2006 12:14:03 +0200

> VFOLDER currently has a number of show stoppers already:

I don't see that as a show stopper. It's the kind of thing developers 
worry about, that's all.

> 2. message going into and out of focus.

Also not a show stopper. It happens seldom, so we can afford to be waste 
bytes when it happens. It's just that we can't break the protocol when 
it happens.

> the draft it is supposed to behave like a real mailbox.

When a message is in several mailboxes and you delete one mailbox (a 
real one or a vfolder), the message does not disappear from other 
mailboxes.

> Why not have filters you can apply to mailbox?

People want their current-day clients to be able to read the vfolder.

Arnt

---

From: Curtis King <[email-masked]>
Date: Fri, 2 Jun 2006 09:34:31 -0600

On 2-Jun-06, at 4:14 AM, Arnt Gulbrandsen wrote:

> I don't see that as a show stopper. It's the kind of thing  
> developers worry about, that's all.
>
> Also not a show stopper. It happens seldom, so we can afford to be  
> waste bytes when it happens. It's just that we can't break the  
> protocol when it happens.

As one who implements these drafts, this is a pain. Tracking UID and  
assigning new UID when a message comes back into focus means you have  
to assign message new UID for each message in a VFOLDER. Not a very  
virtual folder to me.

>> 3. UID issues caused by 1 and 2.

More hand waving here ;)

>> 4. Do you delete messages when you delete the VFOLDER? According  
>> to  the draft it is supposed to behave like a real mailbox.
>
> When a message is in several mailboxes and you delete one mailbox  
> (a real one or a vfolder), the message does not disappear from  
> other mailboxes.

Why not? Wouldn't that be something an end user might want to-do?  
This means messages in a vfolder need a reference count. Once again  
this isn't very virtual from the server perspective.

> People want their current-day clients to be able to read the vfolder.

I agree, but this has been decided in the meeting:

Issue: Legacy clients might duplicate messages since they don't know the
messages are virtual.
Reminder: In Dallas (and on the list) we said that only lemonade clients
could use VFOLDERs.
Discussion: Would be very useful for legacy clients to see VFOLDERs.
Resolution: Allow VFOLDER only for lemonade clients for now.

ck

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 2 Jun 2006 18:19:05 +0200

> to assign message new UID for each message in a VFOLDER. Not a very 

Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT values, a 
search expression and a bunch of uid+uid pairs. Storing less would be 
desirable. But how? The only possibilities I can think of have worse 
consequences, e.g. blocking the way to multi-mailbox vfolders.

Arnt

---

From: Curtis King <[email-masked]>
Date: Fri, 2 Jun 2006 14:15:57 -0600

On 2-Jun-06, at 10:19 AM, Arnt Gulbrandsen wrote:

>> As one who implements these drafts, this is a pain. Tracking UID  
>> and assigning new UID when a message comes back into focus means  
>> you have to assign message new UID for each message in a VFOLDER.  
>> Not a very virtual folder to me.
>
> Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT  
> values, a search expression and a bunch of uid+uid pairs. Storing  
> less would be desirable. But how? The only possibilities I can  
> think of have worse consequences, e.g. blocking the way to multi- 
> mailbox vfolders.

I doubt know if you can, but servers are being force to store more  
information for a VFOLDER than a real mailbox. That just doesn't seem  
like the right design.

Why not have named searches which can be used as FILTERS when  
selecting a mailbox to provide the desired view? Clients can handle  
an UID going out and in of view because they will expect that behavior.

For things like multi-mailbox vfolders why not use a named search and  
copy to populate a new mailbox from the source mailboxes? This may  
require some extensions to search and some way of storing the last  
uid used int the search. Now, the clients can decide when to update  
the mailbox and what messages and flags are synchronized between the  
mailboxes.

This isn't any more work than vfolder, but you can sure do more with it.

I hope I'm making more sense.

ck

---

From: Mark Crispin <[email-masked]>
Date: Fri, 2 Jun 2006 13:27:59 -0700 (Pacific Daylight Time)

On Fri, 2 Jun 2006, Curtis King wrote:
> Why not have named searches which can be used as FILTERS when selecting a 
> mailbox to provide the desired view? Clients can handle an UID going out and 
> in of view because they will expect that behavior.

For what it's worth, I agree with this observation.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Ray Cromwell <[email-masked]>
Date: Fri, 02 Jun 2006 15:25:49 -0700

> the mailbox and what messages and flags are synchronized between the  
Other lemonade extensions (notably notifications) are depending on the 
server to know when to update the "mailbox", not the client. The server 
minimally needs to know that one of the "searches" of interest to the 
client (whether this is implemented as vfolders, filters, or 
search+copy) would have changed, so that the server can tell a client 
(typically a mobile client) to wakeup and go check for changes.  If the 
mobile client had to poll for changes itself, it would be a drain on 
battery life and bandwidth.

The current draft does allow the server to reject searches which would 
allow messages to appear/reappear (e.g. searches based on dynamic 
attributes, or searches using 'within' that would create an interval 
with gaps in it). The real question is, is this really a problem for 
mobile clients, and is the cure worse than the disease? (duplicate 
downloading rarely vs losing the ability to search on dynamic attributes 
or spending bandwidth on ouid/global uid/hash/urls)

-Ray

---

From: Curtis King <[email-masked]>
Date: Fri, 2 Jun 2006 16:50:14 -0600

On 2-Jun-06, at 4:25 PM, Ray Cromwell wrote:

> Other lemonade extensions (notably notifications) are depending on  
> the server to know when to update the "mailbox", not the client.  
> The server minimally needs to know that one of the "searches" of  
> interest to the client (whether this is implemented as vfolders,  
> filters, or search+copy) would have changed, so that the server can  
> tell a client (typically a mobile client) to wakeup and go check  
> for changes.  If the mobile client had to poll for changes itself,  
> it would be a drain on battery life and bandwidth.

Notification is completely separate from updating the content of  
mailbox.

>
> The current draft does allow the server to reject searches which  
> would allow messages to appear/reappear (e.g. searches based on  
> dynamic attributes, or searches using 'within' that would create an  
> interval with gaps in it). The real question is, is this really a  
> problem for mobile clients, and is the cure worse than the disease?  
> (duplicate downloading rarely vs losing the ability to search on  
> dynamic attributes or spending bandwidth on ouid/global uid/hash/urls)

Don't forget about the other half, the server ;) My suggestion of  
using filters avoids duplicate downloading, supports dynamic  
attributes, and notifications.

ck

---

From: Ray Cromwell <[email-masked]>
Date: Fri, 02 Jun 2006 16:37:58 -0700

> Notification is completely separate from updating the content of  

Yes, but from a user's point of view on the client, they probably want 
notifications associated with events related to a particular (virtual) 
mailbox on their client. Let's say I want all messages from the lemonade 
mailing list in the past day to appear on my client grouped in a mailbox 
called 'lemonade' and I want notifications when something changes in 
this "mailbox" on the server.  That means that even if this client side 
lemonade mailbox isn't a real mailbox on the server, but a filter on an 
existing mailbox, the server must still somehow be able to monitor 
filters and know which mailboxes to attach those filters to for the 
purposes of notifications. Moreover, it must somehow tell the client 
which filter applied to which mailbox it should check for updates on. 

It seems we're changing syntax from "SELECT mailbox" to "SELECT mailbox 
VIEW named-view" with the benefit being a possible gain for legacy 
clients. The server would still need to check for messages 
disappearing/reappearing within a view if dynamic attributes are used, 
so it doesn't appear to relieve any pressure on server implementation, 
wouldn't it?

-Ray

---

From: Curtis King <[email-masked]>
Date: Fri, 2 Jun 2006 19:06:02 -0600

On 2-Jun-06, at 5:37 PM, Ray Cromwell wrote:

> It seems we're changing syntax from "SELECT mailbox" to "SELECT  
> mailbox VIEW named-view" with the benefit being a possible gain for  
> legacy clients.

The benefit to legacy clients is from using "SELECT mailbox". But  
since vfolders are available using LISTEXT it's no use for them.  
Besides thinking about it more, vfolders would be very confusing to  
legacy clients.

> The server would still need to check for messages disappearing/ 
> reappearing within a view if dynamic attributes are used, so it  
> doesn't appear to relieve any pressure on server implementation,  
> wouldn't it?

A filter sure does save work. vfolder requires the server to assign a  
new UID to a message in the vfolder. As Arnt pointed out this means  
storing on disk UIDNEXT and a mapping between backing mailbox message  
uid and the vfolder uid. Using a filter I don't have to store any of  
this extra information.

Notifications using vfolder:

1. monitor back-end mailbox for changes.
2. when there is a change see if it matches the search criteria.
3. if adding a new message assign an UID and increment UIDNEXT.
4. if deleting a message decrement message reference count.
5. report changes to client

Notifications using filter:
1. monitor back-end mailbox for changes.
2. when there is a change re-run the search
3, diff the two search results and report the changes.

A filter is much simpler to implement even with extra protocol  
changes needed.

vfolder is filter on backing mailbox pretending it's a real mailbox.  
This overloads what a mailbox is. Why not call a filter a filter?

ck

---

From: Ray Cromwell <[email-masked]>
Date: Fri, 02 Jun 2006 23:28:06 -0700

> A filter is much simpler to implement even with extra protocol  

  Perhaps I'm misunderstanding something, but I don't see how filters 
solve the problem. It seems to me that the difference between vfolders 
and filters is that vfolders apply the filter by default when you select 
a mailbox, and with your filter proposal, they don't get applied unless 
the client asks them to when selecting a mailbox. This by itself does 
not solve the problem of needing to assign new UIDs. Consider the 
following sequence of user actions using "filters"

1) user creates new filter "Flagged Stuff" with search expression 
"SEARCH FLAGGED", client issues command to create this filter on the server
2) user tells client he wants this applied to INBOX creating a new 
'pseudo folder' on his client called "Flagged Stuff" so that when he 
clicks the flagged stuff, he sees only flagged messages
3) user tries to sync "Flagged Stuff"
4) client issues something like SELECT INBOX VIEW "Flagged Stuff" to server
5) client syncs INBOX with this view applied into a separare local 
folder on the client. A message with UID 150 appears in the sequence. 
Client stays in this session with view attached.
6) using a separate client#2 (say, a desktop client), user unflags 
message with UID 150
7) client syncs again (either cause of user action, notification, or 
IDLE). Message with UID 150 is now expunged from local client #1 cache
8) using client #2, user re-flags message with UID 150 in INBOX
9) client#1 syncs again, Message with UID 150 in INBOX must reappear in 
the view of this session. According to my understanding, if this 
happens, it violates IMAP4 guarantees, therefore, it must be given a new 
UID that is greater than all other UIDs in the view.

> This overloads what a mailbox is. Why not call a filter a filter?

  Does it? Does RFC3501 rigorously define what a mailbox is or is it an 
abstraction that can have several implementations? Seems to me that if a 
VFOLDER's semantics are done right, and if it obeys all of RFC3501's 
semantics with respect to how mailboxes behavior, we simply have an 
'is-a' relationship between interface and implementation. Mailbox being 
the interface, and backing mailbox, newsgroup, vfolder, and others being 
implementations of that interface.

-Ray

---

From: Mark Crispin <[email-masked]>
Date: Sat, 3 Jun 2006 09:11:10 -0700 (PDT)

On Fri, 2 Jun 2006, Ray Cromwell wrote:
> semantics with respect to how mailboxes behavior, we simply have an 'is-a' 
> relationship between interface and implementation. Mailbox being the 
> interface, and backing mailbox, newsgroup, vfolder, and others being 

The problem is that VMAILBOX (not VFOLDER) has to complex with IMAP's 
mailbox semantics, but it really isn't an IMAP mailbox, so it has to do 
these various unfriendly kludges with UIDs to avoid the viiolation of 
IMAP, but those kludges cause their own problems.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Curtis King <[email-masked]>
Date: Sat, 3 Jun 2006 16:54:06 -0600

On 3-Jun-06, at 12:28 AM, Ray Cromwell wrote:

> 9) client#1 syncs again, Message with UID 150 in INBOX must  
> reappear in the view of this session. According to my  
> understanding, if this happens, it violates IMAP4 guarantees,  
> therefore, it must be given a new UID that is greater than all  
> other UIDs in the view.

Sorry, I haven't been clear enough.

The above is correct when dealing with a mailbox which Mark explained  
is the problem with VMAILBOX.

What I'm suggesting is not to use SELECT but something new which  
either can be extension to SELECT or an other command like VIEW or  
FILTER. Since its a new command we can change the semantics to better  
meet our requirements like allowing UID go in and out of view.

ck

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 5 Jun 2006 12:20:17 +0200

Curtis King writes:
>> Yes. Agreed. I currently store name, owner, ACL, two UIDNEXT  values, 
>> a search expression and a bunch of uid+uid pairs. Storing  less 
>> would be desirable. But how? The only possibilities I can  think of 
>> have worse consequences, e.g. blocking the way to multi- mailbox 
>> vfolders.
>

All I can say is that I've tried hard and not found any way. For 
example, I thought about some variations that didn't store the UID map, 
but then the server had to look at the entire mailbox at each SELECT 
(or APPLYFILTER, or whatever the SELECT-like command is called). I 
considered variations that involved storing data clientside, but that 
breaks when the user uses both a desktop client and a portable device. 
I tried workarounds for that, such as mandating that the client store 
their clientside data serverside (in METADATA) and use a prescribed 
command sequence to "SELECT". And so on.

> the mailbox and what messages and flags are synchronized between the  

Why don't you write up a draft in some detail and we'll see whether it's 
an improvement?

Arnt

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2006 17:19:22 -0700

At 6:19 PM +0200 6/2/06, Arnt Gulbrandsen wrote:

> think of have worse consequences, e.g. blocking the way to 
> multi-mailbox vfolders.

If there was only one backing mailbox, then maybe you could use the 
real UID as the UID in the vfolder.  I'm bothered by the idea of 
messages going in and out of view and getting a new UID each time.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Resistance is Useless!             (If less than one ohm.)

---

From: Randall Gellens <[email-masked]>
Date: Fri, 9 Jun 2006 17:22:09 -0700

At 2:15 PM -0600 6/2/06, Curtis King wrote:

> information for a VFOLDER than a real mailbox. That just doesn't 
> seem like the right design.
>

I think there was a draft along these lines a few years ago.  From Cyrus maybe?

>  For things like multi-mailbox vfolders why not use a named search 
> and copy to populate a new mailbox from the source mailboxes? This 
> may require some extensions to search and some way of storing the 
> last uid used int the search. Now, the clients can decide when to 
> update the mailbox and what messages and flags are synchronized 
> between the mailboxes.
>

Copying feels like the wrong approach (although some servers may have 
mail stores that allow them to populate the new mailbox with pointers 
to the original message, along with reference counts to handle 
deletion).  What about servers that would have to actually do a copy?

---

From: Curtis King <[email-masked]>
Date: Mon, 12 Jun 2006 16:47:51 -0600

On 9-Jun-06, at 6:22 PM, Randall Gellens wrote:

>>  I doubt know if you can, but servers are being force to store  
>> more information for a VFOLDER than a real mailbox. That just  
>> doesn't seem like the right design.
>>
>> selecting a mailbox to provide the desired view? Clients can  
>> handle an UID going out and in of view because they will expect  
>> that behavior.
>

I think so.

> Copying feels like the wrong approach (although some servers may  
> have mail stores that allow them to populate the new mailbox with  
> pointers to the original message, along with reference counts to  
> handle deletion).  What about servers that would have to actually  
> do a copy?

I agree. I was trying address the multiple mailbox issue which was a  
mistake. VMAILBOX is trying to add a feature best done by the client.  
Be that I mean IMAP is a set of tools which you can do things with,  
VMAILBOX is trying to move a client operation to the server. VMAILBOX  
in it's current form is forcing servers to use a database to store  
uid pairings which raises the implementation bar. Is VMAILBOX worth it?

A number of years back I worked for Esys which produced an MUA  
(Simeon/Execmail) which had virtual mailboxes using IMAP search.  
VMAILBOX can be done today using plain old SEARCH with out much  
difference in performance from what I can see. Wouldn't be better to  
enhance the existing IMAP tools to make this easier? For example:

- save the named searches using METADATA the same way you need to  
save other NOTIFICATION information.
- extend IDLE to filter using a saved search and possible watch  
multiple mailboxes at the same time.
- union searches even from different mailboxes.

ck

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 13 Jun 2006 09:56:58 -0400

Hi Curtis,

>> I think there was a draft along these lines a few years ago.  From

Expired, but available here:

<http://tools.ietf.org/html/draft-ietf-imapext-view-00.txt>

Also along the same vein:

<http://tools.ietf.org/html/draft-ietf-imapext-window-00.txt>

Note that both of these were also trying to deal with the problem of so 
called 'scalability' issues with SORT and THREAD (the fact that a client 
has to issue a SORT/THREAD every time the mailbox changes). That issue lead 
to the level of complexity that ultimately stifled the work. Its seems that 
now that is not as much of a concern (at least the current lemonade drafts 
don't really discuss interaction with SORT/THREAD).

It would certainly be possible to re-do VIEW as a much simpler 'static' 
view of a mailbox without all the extra VIEW id stuff etc and come up with 
something as 'simple' as VMAILBOX.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 14 Jun 2006 11:11:55 +0200

Cyrus Daboo writes:
> Note that both of these were also trying to deal with the problem of 
> so called 'scalability' issues with SORT and THREAD (the fact that a 
> client has to issue a SORT/THREAD every time the mailbox changes). 
> That issue lead to the level of complexity that ultimately stifled 
> the work. Its seems that now that is not as much of a concern (at 
> least the current lemonade drafts don't really discuss interaction 
> with SORT/THREAD).

Right. Because it's orthogonal.

The SORT/THREAD problem applies to users.daboo.ypsilon in the same way 
whether that mailbox is "virtual" or "real".

Arnt

---

From: Curtis King <[email-masked]>
Date: Thu, 15 Jun 2006 14:29:35 -0600

Cyrus thanks for the links to those drafts there are very useful.

On 13-Jun-06, at 7:56 AM, Cyrus Daboo wrote:

> Note that both of these were also trying to deal with the problem  
> of so called 'scalability' issues with SORT and THREAD (the fact  
> that a client has to issue a SORT/THREAD every time the mailbox  
> changes).

Now this is more useful than VMAILBOX.

>
> It would certainly be possible to re-do VIEW as a much simpler  
> 'static' view of a mailbox without all the extra VIEW id stuff etc  
> and come up with something as 'simple' as VMAILBOX.

I agree.

ck