We're not talking about webmail here, but direct access by HTTP request, either from a website or a desktop/mobile client. Some other relevant links for this:
HTTP has had about 20 years of use, development, testing - culminating in SPDY now, which could get even 40% faster in some cases. I'm not sure I can think of a good reason not to make the switch.
There's probably more overhead in the request via HTTP than there is via IMAP, to be honest. I can't see any reason to make this switch other than being able to support port 80.
I guess I'm not really sold on why this is better than IMAP, which is a protocol that, um, actually exists and you can use today.
Fixing the perceived drawbacks of IMAP would seem to be a more productive goal than trying to produce a competing protocol/standard. (Cf. http://xkcd.com/927/)
Microsoft did some early work on HTTP access to email. The Outlook Express client application uses a fully HTTP-based interface to do all mail functions on Exchange mail stores as well as Hotmail. At the time, Hotmail could or did not support IMAP. The Microsoft API uses PROPFIND to list mailbox contents (this mechanism predated Atom by several years).
Exchange also supports WebDAV - Outlook web access uses(d?) it. In fact, this became one of the easiest ways of integrating with Exchange server. Now that Exchange 2007+ has a full web services API, I hear the DAV stuff has been deprecated.
There are severe issues disassociating files from their native character set when you start dealing with east asian languages and the large amount of existing systems that you are dealing with. Forcing everyone in the world to use UTF-8 is not a legitimate option: it's great if you don't already have something more powerful (like MIME), but it should not dismantle existing known/working setups.
You could fairly easily add conneg (yuk) or an alternate json representation to the atom feed... Given that the headers are name value pairs it shouldnt be too hard to standardize.
Multipart MIME is fairly clever in that it provides a reasonably human-readable fallback for old clients that don't support it. I'd be very wary of throwing that out. One of the benefits of plain-text email is its universality.
The only way I can see that working out would be if MTAs and MUAs negotiated during handshaking to decide on what message format they preferred, and then the MTA translated the message either to traditional RFC 2822 or some other preferred format, which could be JSON or pure XML or whatever.
If we're going to keep moving more and more apps from native to Web-based, I think we're going to see a lot more of this (standardizing an existing service to be accessible over HTTP), since WebSockets can't connect to any raw TCP sockets (and they shouldn't, that would be terrible security-wise) and WebRTC has the same approach: a protocol of its own with its own handshake & rules.
Better that than have everyone builds its own incompatible HTTP / REST API for common services.
I do wonder if there's any big companies like Google which have pledged to support this spec?
I'm not familiar with the IETF process, but it says "Expires: April 27, 2009"
With that said, I've been exploring the concept a while back myself. I tend to think of email as the largest "social" network in the world, and I think it's good to give it a sexy web face, and then extend it.
26 comments
[ 2.8 ms ] story [ 64.6 ms ] threadhttp://blog.gaborcselle.com/2010/02/how-to-replace-imap.html
http://blog.webhooks.org/2009/02/13/restful-email-over-http/
HTTP has had about 20 years of use, development, testing - culminating in SPDY now, which could get even 40% faster in some cases. I'm not sure I can think of a good reason not to make the switch.
IDLE? Tagged, out-of-order replies?
You can probably make a SPDY-based protocol that does 99% of IMAP, but HTTP is too limited for current IMAP possibilities.
Fixing the perceived drawbacks of IMAP would seem to be a more productive goal than trying to produce a competing protocol/standard. (Cf. http://xkcd.com/927/)
[...]
Microsoft did some early work on HTTP access to email. The Outlook Express client application uses a fully HTTP-based interface to do all mail functions on Exchange mail stores as well as Hotmail. At the time, Hotmail could or did not support IMAP. The Microsoft API uses PROPFIND to list mailbox contents (this mechanism predated Atom by several years).
The end.
The only way I can see that working out would be if MTAs and MUAs negotiated during handshaking to decide on what message format they preferred, and then the MTA translated the message either to traditional RFC 2822 or some other preferred format, which could be JSON or pure XML or whatever.
Better that than have everyone builds its own incompatible HTTP / REST API for common services.
I do wonder if there's any big companies like Google which have pledged to support this spec?
[1]: https://tools.ietf.org/tools/rfcmarkup/
Actually I think that the CSS is what is appealing, not the source marked up file.
If you want, you can convert Markdown into RFC 2629 documents with <https://github.com/cabo/kramdown-rfc2629>.
With that said, I've been exploring the concept a while back myself. I tend to think of email as the largest "social" network in the world, and I think it's good to give it a sexy web face, and then extend it.
https://github.com/pepijndevos/Wemail