Subject: Re: [MORG] New WG document:draft-ietf-morg-list-specialuse-00

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Feb 2010 20:48:18 -0500

I've updated the draft with everything that's been discussed so far:
http://www.ietf.org/internet-drafts/draft-ietf-morg-list-specialuse-01.txt

Please review and comment further.

Barry

---

From: Dan Karp <[email-masked]>
Date: Tue, 9 Feb 2010 18:24:58 -0800 (PST)

> Please review and comment further.

I don't see any win with RETURN (SPECIAL-USE).  Why not just return the 
extra flags in all cases?

---

From: Jamie Nicolson (倪志明) <[email-masked]>
Date: Tue, 9 Feb 2010 19:07:32 -0800

I see the \Archive flag added. It seemed that its justification was to offer
functionality like Gmail, but I wanted to clarify that Gmail won't support
\Archive. "Archiving" in Gmail just means removal of the Inbox label, which
is accomplished in IMAP by deleting the message from the \Inbox mailbox.

On Tue, Feb 9, 2010 at 17:48, Barry Leiba <
[email-masked]> wrote:

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Feb 2010 22:15:20 -0500

Jamie says...
> is accomplished in IMAP by deleting the message from the \Inbox mailbox.

Right; actually, \Archive was suggested by Filip Navara as a feature
that could be used by systems that handled archiving *differently* to
Gmail.  So, actually, it's a good thing to have another non-Gmail
feature that way.

Dan says...
> I don't see any win with RETURN (SPECIAL-USE).  Why not just return
> the extra flags in all cases?

It's there to be parallel to the CHILDREN case (and it was suggested
by Timo), but you're probably right: computing children *might* be
expensive, but I can't imagine that retrieving mailbox use flags would
be expensive enough that it might be avoided if the client doesn't
care.

Does anyone else have an opinion on this?  Should I pull that out of
the next (final?) version, or should we leave it in?

Barry

---

From: Timo Sirainen <[email-masked]>
Date: Wed, 10 Feb 2010 05:46:31 +0200

On 10.2.2010, at 5.15, Barry Leiba wrote:

> by Timo),

"Suggested" is a bit strong word :) "Wondering" was what I originally used.

> but you're probably right: computing children *might* be

Yes, I didn't think of the cost of computing children flags. The only difference would be reduction of network traffic, but that's quite a tiny amount.

> the next (final?) version, or should we leave it in?

Removing it reduces complexity at least.

---

From: Filip Navara <[email-masked]>
Date: Thu, 11 Feb 2010 16:28:13 +0100

> Please review and comment further.

Ok, one more nitpick. How do I know, as a client writer, to which
level do I need to enumerate the folders in order to detect the
special ones? Most servers have them at the root level, so LIST "" "%"
will list them all. Google has them at second level, so I need to do
the LIST at least two levels deep (eg. LIST "" "%/%" or LIST ""
"[Gmail]/%"). With XLIST I knew that based on the capability I need to
list the folders at least two levels deep (given all the known
implementations) in order to detect the special ones. Using LIST ""
"*" is discouraged and without a capability I will never know how deep
do I need to list the folders. I'd certainly appreciate a guideline
for client writers in regard to this...

Best regards,
Filip Navara

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 11 Feb 2010 17:50:04 +0200

On Thu, 2010-02-11 at 16:28 +0100, Filip Navara wrote:
> "[Gmail]/%").

First thought that comes to my mind: Add yet another flag, such as
\HasSpecialChildren.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Feb 2010 17:04:24 +0100

> First thought that comes to my mind: Add yet another flag, such as

Listext added "selection options" for such things. Is there any reason 
to avoid that?

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 11 Feb 2010 18:23:20 +0200

> Listext added "selection options" for such things. Is there any reason 

Well, I thought of two ways, neither one really seems much better:

a)

C: C04 LIST (SPECIAL-USE RECURSIVEMATCH) "" "%"
S: * LIST (\Noselect \HasChildren) "/" "[Gmail]" ("CHILDINFO" ("SPECIAL-USE"))
..
S: C04 OK done

But RECURSIVEMATCH seems to be described in a way that it's used only
when some other option otherwise filters out mailboxes. So the above
would mean more like "show only special-use mailboxes", and the LIST
would give only the one [Gmail] mailbox reply.

b) 

C: C04 LIST (SPECIAL-CHILDREN) "" "%" 
S: * LIST (\Noselect \HasChildren) "/" "[Gmail]" ("SPECIAL-CHILDREN" "1")
..
S: C04 OK done

Or something like that .. This seems pretty horrible though.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Feb 2010 17:38:37 +0100

> Well, I thought of two ways, neither one really seems much better:

Why would anyone bother with %? There are only a few special-use 
mailboxes, so just get all of them at once:

   a list (special-use) "" "*"

% is fine for progressive discovery, but why should one progressively 
discover four mailboxes?

Arnt

---

From: Filip Navara <[email-masked]>
Date: Thu, 11 Feb 2010 17:41:00 +0100

On Thu, Feb 11, 2010 at 5:38 PM, Arnt Gulbrandsen
<[email-masked]> wrote:
> Why would anyone bother with %? There are only a few special-use mailboxes,
> so just get all of them at once:
>

The specification didn't depend on LISTEXT, now it would. I'm fine
with that as long as the server implementers support it.

Filip

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Feb 2010 17:46:50 +0100

> with that as long as the server implementers support it.

Good point. IIRC the usual suspects already have listext 
implementations, but I note that gmail does not. Anyone else? Is it 
acceptable to depend on listext?

Arnt

---

From: Filip Navara <[email-masked]>
Date: Thu, 11 Feb 2010 17:49:15 +0100

On Thu, Feb 11, 2010 at 5:46 PM, Arnt Gulbrandsen
<[email-masked]> wrote:
> Filip Navara writes:
>>
>> The specification didn't depend on LISTEXT, now it would. I'm fine with
>> that as long as the server implementers support it.
>
> Good point. IIRC the usual suspects already have listext implementations,
> but I note that gmail does not. Anyone else? Is it acceptable to depend on
> listext?

Kerio has it, Gmail and IceWarp doesn't. I don't know of anyone else
who implemented XLIST.

Best regards,
Filip Navara

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 11 Feb 2010 18:50:44 +0200

> acceptable to depend on listext?

I was going to first mention this in my email, but then I thought maybe
you after all meant to use only LISTEXT syntax, not actually depend on
LISTEXT.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 11 Feb 2010 17:54:22 +0100

> you after all meant to use only LISTEXT syntax, not actually depend on

Fine idea, if you ask me.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 11 Feb 2010 19:03:54 +0200

> % is fine for progressive discovery, but why should one progressively 

Then it would require two LIST commands:

a list (special-use) "" *
b list "" %

Is that a real problem (from client implementers' point of view)?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Feb 2010 20:31:30 -0500

> First thought that comes to my mind: Add yet another flag, such as

I don't think I like that idea.
I'd rather see a LISText option to list all of the special-use mailboxes:

      C: T1 LIST (SPECIAL) "" "*"
      S: * LIST (\Sent) "/" SentMail
      S: * LIST (\Marked \Drafts) "/" MyDrafts
      S: * LIST (\Trash) "/" Trash
      S: * LIST (\Archive) "/" "Saved/Mail/Archive"
      S: T1 OK done

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 12 Feb 2010 15:33:07 +0100

> I'd rather see a LISText option to list all of the special-use mailboxes:

Would you be happy with something that uses listext syntax, without 
requiring a full listext implementation in the server? (As I can claim 
Timo suggested and Timo can claim I suggested. Good to have plausible 
deniability when bringing up such a hack :-)

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 13 Feb 2010 06:10:32 +0200

>       S: * LIST (\Archive) "/" "Saved/Mail/Archive"

I was also hoping that clients that currently support XLIST might
automatically recognize these \flags even without XLIST
capability/command. That could work only if regular LIST command listed
those flags. But I haven't tested if that actually works.