Re: [imap5] Designing a new replacement protocol for IMAP

[Bron Gondwana <[e-mail]>]

On Wed, Feb 15, 2012 at 09:59:56PM +0100, Michel Sébastien wrote:
> 
> >> On 15/02/2012 14:19, Bron Gondwana wrote:
> >> > On Wed, Feb 15, 2012, at 02:11 PM, Tony Finch wrote:
> >> >> Is there any reason to keep subscriptions in IMAP 5 ?
> >> > I envisage "subscription" as either an annotation or a "Special Use"
> >> > on a folder rather than yet another axis of data.
> >> +1.
> Does it works with shared folders ?

Sure, it's a private annotation.

> > This is not a problem that's unique to email.  There's nothing really special about email here unless you make it special.  Sure there's a bunch of indexed and optimised ways of viewing that data - sort by trimmed subject, encodings, etc.  All of which could be expressed as generic queries against the data model with a query optimiser on the far end rather than needing a custom syntax for everything...
> >
> 
> Some others seems to think that webdav could be a candidate : http://www.webdav.org/other/faq.html#Q26
> A new layer on top of webdav, with some keywords registered at IANA. But I just don't like the trend to use HTTP for everything... despite its interest here.

Yes, webdav is tempting for a few reasons - the downside is
a relatively high overhead.

BEEP has also been mentioned.  A good advantage of both of
these is that you can transport unmodified MIME across them.
I'm wary of anything which will require the raw MIME bodies
of messages to be encoded across the wire - some sort of
length based literal syntax is very valuable.

Of course it's hard to love something with examples like this:

 S: RPY 0 1 . 221 185

 S: Content-Type: application/beep+xml
 S:
 S: <profile uri='http://iana.org/beep/SASL/CRAM-MD5'>
 S: <![CDATA[<blob>PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1
                                               jaS5uZXQ+</blob>]]>
 S: </profile>
 S: END
 
It makes MIME header encoding look so lightweight in comparison.


Still... as I'm regretting learning, compatible is more important
than good.  If there exist libraries everywhere which can
reliably read and write that, and it's ugly enough that nobody
wants to do it themselves, then maybe - just maybe, you'll actually
get BETTER complience than if it's a simple enough protocol that
people roll almost-correct code by hand.

Bron.