MBOX-Line: From dave at cridland.net  Thu May 31 01:18:10 2007
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Subscriptions in IMAP
In-Reply-To: <alpine.WNT.0.99.0705301555120.2080@Shimo-Tomobiki.Panda.COM>
References: <alpine.OSX.0.99.0705301048240.11683@pangtzu.panda.com>
	<20070530113546.Q27473@orthanc.ca>
	<alpine.WNT.0.99.0705301146290.5388@Shimo-Tomobiki.Panda.COM>
	<BF01B191-D34E-47DE-A4FB-EAF1CADE4715@apple.com>
	<1180563766.32181.2028.camel@hurina>
	<alpine.WNT.0.99.0705301555120.2080@Shimo-Tomobiki.Panda.COM>
Message-ID: <8046.1180599490.471444@peirce.dave.cridland.net>

On Thu May 31 00:00:14 2007, Mark Crispin wrote:
> I am starting to think that the solution is to remove subscriptions 
> from IMAP entirely, and replace it with a mechanism to stores a 
> list of IMAP URLs.

That's an interesting viewpoint to me, because I have been toying 
with the idea of doing more or less this in Polymer - namely, keeping 
a list of IMAP URLs (possibly including SEARCH components) in a 
heirarchical layout within Polymer's ACAP store, and using this as 
the primary navigation tree.

My reasoning was that this would allow for the user to map the 
mailbox heirarchy wholly independent of server layout, and gain more 
advantage from things like CONTEXT, keywords, etc.

My reasoning for not using subscriptions is (as it's always been) not 
a problem with subscriptions, per-se, but a problem with their use by 
multiple clients. There's almost as many interpretations of what 
subscriptions are, and how to use them, as there are clients, and 
there's little guidance within the RFCs to explain them.

I'm not blaming Mark, or the others involved in RFC3501 here - it's 
understandable that the semantics of a subscribed mailbox weren't 
fully described in the original design, because the intent was 
obvious - unfortunately, as time has moved on, it's less obvious, and 
requires a certain degree of archeology to detirmine what the intent 
was, and besides, we have multiple clients gradually pulling the 
intent in different and contradictory directions.

I *think* that a subscribed mailbox is one that the user has declared 
an interest in monitoring, specifically for new messages. Equally, I 
*think* that, like a browser bookmark, one might present a shortcut 
menu directly to them. And I *think* that that menu might be the 
default navigation tree for some clients quite sensibly - for 
instance mobile devices.

Finally, I note that there are different demands on a 
subscription-like system now, in particular, those mailboxes which 
interest the user on a mobile device (where you almost certainly 
don't want to monitor everything closely) are likely to be different 
to those on a desktop machine.

I did suggest, a while back, that we should look at providing 
user-defined keywords on mailboxes, as we do on messages already, as 
a potential replacement to subscription, but the consensus seemed to 
be against this, in favour of reworking the idea as a further nail to 
METADATA's hammer, whereas I really wanted something much simpler.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

