On Thu, Feb 09, 2012 at 12:25:33PM +0100, Giovanni Panozzo wrote: > >I found some older initiatives to replace IMAP with an HTTP based > >approach.[2] > >What do you think of HTTP for mail access? For my bachelor thesis[3] I > >currently argue that CardDAV/CalDAV could be perfectly replaced by AtomPub > >(RFC 5023). > >The main advantage would be that most software developers on this planet have > >some vague understanding of HTTP and that imense infrastructure and software > >already exists. > > > Hi Bron, hi Thomas. > I'm happy to see this interesting traffic on the ML. > > Just a small note: these two post are full of "programmer point of > view" considerations and philosophical ideals. That's good. > > But I'm mostly "system integrator", involved also with end-user > helpdesk. I'm a programmer also, but only form 2% of my time, so I'm > not a "professional programmer". > I would like to contribute with other key points useful both to > system integrators, helpdesk and end user (moron end user) ease to > use (I have a long list... do you want it ? :))
Yep! I do all of those too, though programming is a larger part of my week. There's a lot of sysadmin and user operations - and third level support. I'm not doing much first level any more. > Here are my first notes about HTTP: I think HTTP is welcome. Many > mobile phone carriers do offer only http/https connectivity, > sometimes filtered by a transparent proxy too. In some enterprise > LANs, users are forced to use an http proxy with proxy > authentication to access the Internet. No other protocols are > allowed. HTTP would allow all these users to access their e-mail > without requiring impossible access upgrades. > And HTTP completed with digest authentication and email body > encryption also will also help sysadmins to have more security > without incurring into the SSL certificate infrastructure pains. > Http is also "stateless" from its birth: the advantage is that we > can better serve clients with intermittent connections (point 3 in > Bron's list), like mobile phones or poorly connected wifi laptops. That's certainly a strong point in HTTP's favour. I'm going to spend some time on the wiki tonight (Oslo time) building up a list of the major technology choices and the advantages and disadvantages of each one. Protocols will basically be: * Custom * HTTP * XMPP And within HTTP: XML / JSON / other? RESTful URIs vs batching... One important point - I don't want to lose "literals". RFC822 messages should be able to zero-copy IO across the wire as the raw bytes. Bron. _______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
