having dealt with support issues relating primarily to HTTP for the last
17 years, I'd STRONGLY recommend against using anything HTTP based. The
number of proxies that break WebDAV makes it problematic alone.
If some clients need HTTP-based access to some IMAP function, they can
use a gateway.
Then an administrator can choose whether to allow such access. But
clients using the protocol that provides it all don't need it.
If you're a system admin, and there's a product you can install where
you install 1 service, open 1 port and it provides everything you'd go
for that right?
If we play our cards right, it should be simple for some gateway to
provide legacy interfaces to the new protocol.
re the discussion about richness of protocol... sure you can do things
at a lower level. That typically requires more round-trips to the
server though.
unless the things are pipelined..... specifically designed to be, so a
single meta command is sent as a bunch of micro commands... but therein
lie a multitude of problems (e.g. enforcing security, synchronisation etc).
Adrien
On 16/02/2012 10:13 a.m., Bron Gondwana wrote:
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.
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
